I don't have a strong lean either way too. Either way, this gives integrators and tooling stability on these contracts while allowing our team to retain some flexibility. As I mentioned on HipChat, I've often seen o.h.mapping as a Hibernate internals only package (even as a user), and so exposing something with a bit more "guaranteed lifespan" is certainly not a bad idea. I could allow Koen, other tooling, and integrations to remain compatible longer or at least bridge the gap so their release stream doesn't necessarily have to be absolutely in accordance with our own.
At the very least an SPI would be useful. I think an API has the best ROI for tooling/integrators long-term. On 03/23/2017 05:54 AM, andrea boriero wrote: > I do not have a strong opinion about it, but I'm leaning towards defining > this as an SPI > > On 22 March 2017 at 18:15, Steve Ebersole <st...@hibernate.org> wrote: > >> Coming back to this to see if people see this as an API concern, of if we >> should define this as an SPI. >> >> One potential argument for making it an API is that it is *conceivable* >> that this model could potentially be walked by the same visitors as >> described in another thread regarding "model navigation". I would not say >> that this is likely, as it would probably hamper the usefulness of this >> navigation when applied to the runtime model which is where I think we >> really want to focus our attention regarding navigation. >> >> On Mon, Feb 27, 2017 at 9:51 AM Steve Ebersole <st...@hibernate.org> >> wrote: >> >>> No replies, so changing... >>> >>> On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <st...@hibernate.org> >>> wrote: >>> >>> For 6.0, what do y'all think of these changes proposed below to the >>> org.hibernate.mapping package? >>> >>> *Koen, this affects tools so really would like your thoughts...* >>> >>> Mostly this comes from the definition of a `#finishInitialization` method >>> on ManagedTypeImplementor (which covers mapped-superclass, entity and >>> embeddable/embedded). Currently this method takes its supertype as >>> PersistentClass; however PersistentClass is generally understood to model >>> an entity and tooling certainly uses it as such. Keeping this in mind to >>> hopefully minimize impact I propose the following: >>> >>> >>> 1. Define a new org.hibernate.mapping.ManagedTypeMapping that >>> represents mappings for any "managed type" in the normal JPA meaning >> of >>> that term (mapped-superclass, entity, embeddable) >>> 2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending >>> ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we >> split >>> EmbeddableTypeMapping and "EmbeddedMapping"? >>> 3. Define a new org.hibernate.mapping.IdentifiableTypeMapping >>> extending ManagedTypeMapping >>> 4. Define a new org.hibernate.mapping.MappedSuperclassTypeMapping >>> extending IdentifiableTypeMapping >>> 5. Define a new org.hibernate.mapping.EntityTypeMapping extending >>> IdentifiableTypeMapping >>> 6. Make PersistentClass extend EntityTypeMapping and deprecate >>> 7. Make Composite extend EmbeddedTypeMapping and deprecate >>> 8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and >>> deprecate >>> 9. Re-work the hierarchies here to better fit this new model >>> >>> >>> /** >>> * ... >>> * >>> * @todo (6.0) Use ManagedTypeMapping here as super-type rather than >>> PersistentClass >>> */ >>> void finishInitialization( >>> ManagedTypeImplementor<? super T> superType, >>> PersistentClass entityBinding, >>> PersisterCreationContext creationContext); >>> >>> >>> >> _______________________________________________ >> hibernate-dev mailing list >> hibernate-dev@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
