6:18 a.m.
Hey Steve,
Changing the mapping model as you propose will definitely have impact on the tooling code.
Concepts like Table, Column and ForeignKey are present in the SPI that was devised to
isolate the Hibernate runtime code from the Eclipse tools. However, this layer is not cast
in stone and it also allows for some flexibility as changes in the core model can be
adapted to be consumed by the Eclipse tools. So my gut tells me that it will probably be
doable for the Eclipse tools code to work with these kind of changes. But tooling is
anyhow supposed to be there to make work with the runtime easier and not the other way
around ;-)
As for the impact these changes will have on the reverse engineering tooling, this will
probably be more important. But since I am only working with this codebase for a
relatively short period, I cannot assess with certainty if it would require a lot of
rewriting or if it would be enough to just use the new core concepts with the old tooling
principles.
Not sure if this answers your questions?
Cheers,
Koen
Op 24 okt. 2015, om 20:40 heeft Steve Ebersole
<steve(a)hibernate.org> het volgende geschreven:
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(a)hibernate.org
<mailto:steve@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
<https://hibernate.atlassian.net/browse/HHH-10213>