Proposal Loader redesign

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:

• statically from result-set-mapings, HQL specifications, etc
• dynamically based on fetch profiles etc

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)

Proof-of-concept work is housed at https://github.com/sebersole/hibernate-loader-redesign

Jira is at https://hibernate.onjira.com/browse/HHH-7841

More to come...