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
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
fetch plans.
That said, I should p
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 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
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 navigatio
No replies, so changing...
On Mon, Feb 20, 2017 at 11:02 AM, Steve Ebersole
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
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,
