Hello! I'm using qualifiers to provide alternative serialization strategies (i.e. different ArgumentFactorys)
for a particular type. This works very well, except when it comes to binding Collections/Streams/Iterables (à la StatementContext::bindList
Comments in the original Qualified Types pull request
describe some of the obstacles to implementing qualifiers that apply to elements of an Iterable. In particular, questions about syntax and its semantic implications, as well as the challenges imposed by the obstinate reflections API. It's possible that my understanding is flawed, so please correct me if I'm wrong, but it seems to me that these particular issues are exclusive to the declarative SQL Object usage. I'm not identifying any concerns about implementing this in the core fluent API.
Given all of that, I am curious to know:
- Are there currently any known or suspected challenges that would impede the implementation of Iterable-of-qualified-type argument binding in the core API alone?
- Is there a stated or unstated goal to keep perfect feature parody between core and declarative APIs? I realize this is the ideal, but I would rather have a feature only in the core API if the alternative is to have it in neither. I didn't see anything in CONTRIBUTING.md that explicitly suggests this aspiration, but perhaps I am not looking in the right place.
Anyway, thank you for all the work you've put into this library. I find it to be both practical and enjoyable to use. I appreciate any feedback you are willing to offer on this topic.