[hibernate-dev] Some proposals

[Steve Ebersole]

Thanks for verifying that Koen.  I'll run the changes (if any) to the
domain model mapping classes (PersistentClass, Component, etc) from
o.h.mapping after I get to them before we finalize anything.

On Mon, Oct 26, 2015 at 3:12 PM Koen Aers <koen.aers at gmail.com> wrote:

> Hey Steve,
>
> The changes that you describe below will have almost no impact on the
> tooling. It requires the removal of IColumn.getValue() but AFAICS this
> functionality is only used twice and I am even not sure if it should be
> used where it is used. I am pretty sure there is an easy way to deal with
> the change in those places.
> I am not sure if I understand completely what the exact changes are that
> you plan for PersistentClass, RootClass and Component. At this point in the
> tooling SPI there is only an IPersistentClass interface and a IType
> interface. A number of methods allows to check if the type is a component
> or another kind of type and some of the interface methods only apply to
> particular kind of types. This is probably something on the tooling side
> that needs to be improved later on by reviewing the SPI. But as I
> understand it, these changes would also have no impact for the current
> tools.
>
> I hope this helps a bit.
>
> Cheers,
> Koen
>
> Op 26 okt. 2015, om 15:49 heeft Steve Ebersole <steve at hibernate.org> het
> volgende geschreven:
>
> So here are the general proposals per object:
>
> 1) Column - The main change proposed is to distinguish between the logical
> name and physical name of a Column, so I propose that we keep both on the
> Column for easier access.  I also propose that we remove Value from being
> stored on Column; it is an awkward mapping - a column can be referenced by
> multiple Value objects.  I also removed methods that are better handled
> elsewhere.  I created a gist of the full diff[1].  If that is too much, I
> also created a gist of just the diff for the instance state[2] so its
> easier to see the proposed changes
> 2) Table - the main change proposed here is around storing and accessing
> Columns.  The legacy code required that you build a Column instance to pass
> into the Table to ask if that Column exists in the Table.  Its awkward.
> The proposal is to maintain a Map of columns by both the logical and
> physical name (afaik we only ever access the column by logical name, so the
> second Map is maybe unnecessary.  However, we do want to make sure that the
> the physical names are unique as we add columns which would require
> iterating over all columns and checking if we did not have the second Map.
> I again removed some methods that are better handled elsewhere.  Again
> there is a full diff[3] and a smaller one[4]
>
> I did not (yet) implement any of the "managed type" changed mentioned
> before.  I wanted to wait to hear back from you and talk through those with
> you first.
>
>
> [1] - https://gist.github.com/sebersole/ec53bbc02419fb261825
> [2] - https://gist.github.com/sebersole/e6fd42fb2d7b79f7ecc4
> [3] - https://gist.github.com/sebersole/ce0a047edc0d4c68bd6e
> [4] - https://gist.github.com/sebersole/6676abc04ec1b9266304
>
> On Sun, Oct 25, 2015 at 2:04 PM Steve Ebersole <steve at hibernate.org>
> wrote:
>
>> Really its a question about planning.  The current model is very limiting
>> in many respects.  We have been planning on whole-sale replacing it for
>> some time.  This is a proposal to limit the breadth of the changes to just
>> the relational model to extend the lifetime of the rest of the model (I
>> assume tooling uses most of the org.hibernate.mapping package, which is the
>> "model" discussed here).  The relational part of the model is the most
>> limiting, so the proposal is to change up those minor pieces.
>>
>> Again, the idea is to do some minor work now to extend the lifetime of
>> the model overall.  Another option is to identify the biggest current
>> obstacles and tweak those as needed here and really extend this lifetime.
>> I mentioned the relational part.  The other piece that would be nice is to
>> unify the concept of inheritance and "attribute containers".  Basically to
>> improve the model for what JPA calls ManagedType, IdentifiableType,
>> MappedSuperclass, Entity, Embeddable; essentially to apply the modeling
>> these concepts as we developed in the metamodel branch[1] to
>> PersistentClass, RootClass, Component, etc.
>>
>> So the idea would be to apply smaller set if changes to the existing
>> contracts in order to better suite what we need.  The contracts would
>> change slightly, so it would still require some changes in the tooling, but
>> it would be less than a wholesale change.  I'll work up the proposed
>> changes and follow up here.
>>
>> [1]
>> https://github.com/hibernate/hibernate-orm/tree/metamodel/hibernate-core/src/main/java/org/hibernate/metamodel/spi/domain
>>
>> On Sun, Oct 25, 2015 at 6:18 AM Koen Aers <koen.aers at gmail.com> wrote:
>>
>>> 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 at 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 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
>>>>
>>>>
>>>>
>>>
>