[hibernate-dev] Some proposals

[Steve Ebersole]

Getting some proposals that have been rolling around in  my head down on
paper (electronically speaking)..

*Caching SessionFactory state*

The Jira[1] contains the details.  The basic gist is to allow for slimming
down the in-memory size of the SessionFactory based on how we store certain
SF-scoped state.  I do not have hard numbers that this would help
performance, but I do know that the SessionFactory can be a large hit to
"old gen" memory on a lot of systems and that minimizing the amount of such
memory space in general helps with the operational performance of the VM;
so I thought it might be worth some exploration.  Let's please discuss this
one on the Jira.  Add any thoughts you may have, or vote it up if you think
it makes sense.


*Merge hibernate-core and hibernate-entitymanager*

This is one we have discussed before.  There is not a Jira for it
specifically afaik.  The idea would be to merge together the core and hem
modules into a single module (jar).  This has a lot of different benefits,
which we have discussed before.  The reason I am bringing it up now (again)
is that there is a new looming benefit as we work on SQM.  At the moment
SQM defines its own "metamodel" contracts (org.hibernate.sqm.domain
package).  However, if we merged core and hem that would mean that the
Hibernate core stuff would have access to the JPA metamodel definitions and
therefore we could define SQM in terms of the JPA metamodel.

The issue that has held us back in the past is different behaviors in the
different event listeners implementations for certain events.  However, I
think every hard limitation is a result in listener and PC design in
regards to cascading in that the listener itself says what operation to
cascade.  So, e.g. in core save/persist/merge/update operations are
cascaded as save-update, whereas those operations in the JPA-based
listeners cascade as merge.  This has been the one sticky point that has
held us back from doing this merging previously.  The problem (imo) is that
the PC has no concept of a "current operation context".  This is why, e.g.,
you see listeners for cascadable operations define method overloads; one
taking a "context Map" and one not.  Gail and I have discussed actually
adding a concept such as this "current operation context" to the PC as a
way around some other limitations and it would certainly help here too.


*Some changes to mapping model*

The inclusion of the completely new "mapping model" is being delayed
indefinitely.  In the meantime, I do propose that we pull some of the
improvement concepts over to the existing mapping model (as defined in
org.hibernate.mapping).  Most of the changes I propose relate to relational
side.  A lot of it deals with aggregating related state (OO design).

Koen, I'd especially like you thoughts as this would represent another
change that I think affects you in tooling code.  This would be work done
as part of the "jandex-binding" work, which is still to-be-scheduled, so
it's not like it adds work for you tomorrow :)

Some (not exhaustive) specific changes include:
* As mentioned above, I'd really like to rework at least the relational
side.  Specifically replace org.hibernate.mapping representations of Table,
Column, Formula, etc with definitions more in line with the definitions we
worked on in metamodel.  This includes tables, columns, etc understanding
the split between logical and physical naming, and keeping reference to
both.
* Defining associations based on a ForeignKey, rather than just a
collection of columns (encapsulation).  Whether the ForeignKey is generated
is a whole different story.
* More aggregation at the binding level.  For example, RootClass currently
exposes multiple pieces of information about an identifier (pk), rather
than just a single "identifier descriptor".  Same for caching descriptor,
"fetching characteristics", etc.


[1] - https://hibernate.atlassian.net/browse/HHH-10213