We plan to add support for native NoSQL queries in Hibernate OGM. We'd like to re-use the ORM infrastructure for this. This requires to make the routine of identifying named (and positional) parameters customizable. Currently this routine - naturally - is specific to native SQL queries (see QueryPlanCache#buildParameterMetadata(), ParamLocationRecognizer). For our purpose we'd need a way to customize the parsing routine, so Hibernate OGM could plug-in alternative implementations.
But to me it seems like these would always be changed in "lock step", meaning I cannot really see a use case for wanting to override your ParameterMetadataRecognizer but not your QueryPlanFactory, nor vice versa. (Also, I very much dislike the name QueryPlanFactory when the thing in fact only deals with native queries, very misleading IMO)
I see where you're coming from and I'd agree when taking only native queries into account. In fact I named QueryPlanFactory that generic though in order to allow for the addition of other query plan creation methods in the future, should that need arise. I haven't thought this through till the end, but I felt this might be required for OGM at some point. I contemplated to add e.g. createHQLQueryPlan() right now but then I don't need it at this point and thus refrained from doing so. But it might actually make sense to add it and be done with it.
But I think we need to review what we want that to expose. In fact, I'd suggest we also review handling of native queries overall in light of lessons-learned as well as new requirements for OGM, etc.
The idea that you'd want to separately (1) process parameters and (2) build query plan for native queries just does not make sense to me, regardless of whether pluggable HQL handling is(not) included too.
You're right, these two things (getParameterMetadata(), createNativeQueryPlan()) will be customized together. So +1 for merging this into one contract. We still may add another contract such as HQLQueryPlanFactory in the future should there be the need for it.
To be honest, I am not sure we will need something like a HQLQueryPlanFactory given the work for the HQL Parser project. But that's a separate topic was just my point.
I'll work on consolidating these into one contract then for 4.3 and on master. For the time being I'll not add a NativeQueryPlan interface until we can revisit that properly.
Closing resolved issued in preparation for releasing 4.3.6.