Loader is an internal contract. The basic idea is that it builds SQL, prepares the Statement and processes the resulting ResultSet. To do that it follows the common legacy Hibernate pattern of class hierarchies; so there is a specific Loader impl for loading from a HQL query or batch loading or native-sql query or ... Al in all pretty inflexible.
What I envision here instead is Loader as a basic "coordination contract" which takes a ResultSet and a LoadPlan and knows how to process the ResultSet in terms of said LoadPlan. Currently LoadPlan does not exist, although to a degree it is a function of the current contract between the base Loader class and its subclasses. That just needs to be cleaned up and formalized.
The reasoning here is that this would allow better reuse of instances. LoadPlans could be built:
Also the LoadPlan would remain the same whether we are batching or not, how many ResultSets we are processing (think chained ResultSets or procedure cursor output params)
An optional goal is to help OGM reuse as much of the generic code as possible. Today
OgmLoader is a copy paste from the Hibernate ORM code later adapted to use the NoSQL GridDialect. This goal is not a must have of the Loader redesign but rather a nice to have.
List of things to consider in implementing:
See https://hibernate.onjira.com/browse/HHH-7841 and related Jiras.
Initial proof-of-concept work is housed at https://github.com/sebersole/hibernate-loader-redesign. However, work has now moved beyond that initial proposal. In fact this proposal has really become a few distinct proposals: