Make it customizable how parameters in native queries are detected
Description
Activity
Former user July 10, 2014 at 5:58 AM
Closing resolved issued in preparation for releasing 4.3.6.
Steve Ebersole May 21, 2014 at 5:10 PM
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.
Gunnar Morling May 21, 2014 at 4:46 PM
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.
Steve Ebersole May 21, 2014 at 4:27 PM
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.
Gunnar Morling May 21, 2014 at 4:10 PM
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.
+1
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.