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.a...@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 <st...@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 <st...@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.a...@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 <st...@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 <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
