Having this as an SPI could be useful to Hibernate Search.
For example when we generate queries to efficiently scroll on large
batched of entities while fetching a selection of relations having
some more details on such relations could allow us to suggest better
That said, I should prototype it first to get a better feeling of the
usefulness, and I'm fine in using implementation details for such
experiments, so I'd be equally happy if you'd want to keep this
semi-private and eventually promote as SPI as needed.
In short, the Search needs can be deferred so I'd base the decision on
the needs of other use cases.
On 23 March 2017 at 09:54, andrea boriero <dreborier(a)gmail.com> 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>
> > 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
> > 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
> > 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 mailing list