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
this as an SPI
On 22 March 2017 at 18:15, Steve Ebersole <steve(a)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 <steve(a)hibernate.org>
>> No replies, so changing...
>> On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole <steve(a)hibernate.org>
>> 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
>> that term (mapped-superclass, entity, embeddable)
>> 2. Define a new org.hibernate.mapping.EmbeddedTypeMapping extending
>> ManagedTypeMapping (org.hibernate.mapping.Composite). Or should we
>> 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
>> 6. Make PersistentClass extend EntityTypeMapping and deprecate
>> 7. Make Composite extend EmbeddedTypeMapping and deprecate
>> 8. Make MapppedSuperclass extend MappedSuperclassTypeMapping and
>> 9. Re-work the hierarchies here to better fit this new model
>> * ...
>> * @todo (6.0) Use ManagedTypeMapping here as super-type rather than
>> void finishInitialization(
>> ManagedTypeImplementor<? super T> superType,
>> PersistentClass entityBinding,
>> PersisterCreationContext creationContext);
> hibernate-dev mailing list
hibernate-dev mailing list