[hibernate-dev] Some proposals

[Steve Ebersole]

Koen, any thoughts on the "mapping model" proposal?  FWIW, silence on this
list is taken by me to mean implicit agreement for me to do whatever I want
;)


On Wed, Oct 21, 2015 at 8:04 AM Steve Ebersole <steve at hibernate.org> wrote:

> 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
>
>
>