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 <st...@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 > > > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
