Some time ago I submitted a minor bug having to do with named sql query mapping/binding (http://opensource.atlassian.com/project ... e/HHH-3108) and got lately to fix it. Hibernate page mentions that contributions should be submitted in patch format, but doesn't say to what version - I presume last stable one, that is 3.2.6.ga?

As I already spent some time debugging and got a basic understanding of the code, I thought I might add some functionality I heavily miss. The question is, is it possible for such a user contribution to make it to be incorporated into the code? If so, what would be the procedure and requirements? And where and whom should I contact in the matter?

My issues with hibernate I'd like to fix concern efficiency and control of fetching whole graphs of objects with many associations:

1. First of all, a possibility for specifying a custom collection loader for fetch='subselect' on a per-query basis. The root query would be able to define a subselect query used to fetch collections owned by returned entities (ideally also nested associations). If original query is complicated (involves joins or subselects), current solution is highly ineffective and I found I could often write optimized queries returning the same data. This is especially pronounced when a large percentage of total data in the table is returned by associated queries.

2. Do some automatic optimization for fetch="subselect". Most notable example is fetching collections defined in subclasses of an entity returned by a polymorphic query. When using table-per-concrete-subclass approach, first query results in an SQL with a couple of joins, and is then used literally as a subselect in the query for associated objects. In most cases it would be sufficient to do the subselect only against the base class table.

3. Allow to use HQL queries as collection loaders, not only SQL queries. I don't know, maybe you're currently working on it - it seems so natural and I've seen a feature request in JIRA.

It would be great if it would be possible to introduce these features to hibernate - the lack of 1) pushes us to drop hibernate for a more flexible, low-level solution in some projects having a complex graph of classes (arguably exactly those which would really benefit from a model-driven persistance approach). Unfortunately, there's no way my company would allow usage of an in-house patched version of hibernate,
so my work on such a patch would be a waste of time if it didn't make it to a release one day.