Re: [hibernate-dev] Some proposals

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(a)hibernate.org&gt; 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(a)hibernate.org&gt; 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/... > > On Sun, Oct 25, 2015 at 6:18 AM Koen Aers <koen.aers(a)gmail.com&gt; 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(a)hibernate.org&gt; >> 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&gt; >> 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 >>> >>> >>> >>