In that case I'd say let's do it if it makes sense :)
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 10.03.2017 um 00:14 schrieb Steve Ebersole:
That's basically exactly what @Incubating means - we are exposing this
new API/SPI but users should fully expect the contracts to change.
Basically the annotated API/SPI is not held to our normal
compatibility rules - this is a new thing and we assume it will evolve
in use
On Thu, Mar 9, 2017, 3:16 PM Christian Beikov
<christian.beikov(a)gmail.com <mailto:christian.beikov@gmail.com>> wrote:
Is there a definition to what @Incubating means? I'd rather not
make it
an API until we played a little with it for new features.
Mit freundlichen Grüßen,
------------------------------------------------------------------------
*Christian Beikov*
Am 09.03.2017 um 17:35 schrieb Steve Ebersole:
> Currently in 6.0 we have the notion of a Navigable which models
any "piece"
> of the application's domain model[1]. We also have the notion of
> a NavigableVisitationStrategy which defines the strategy for
handling the
> visitation of the nodes in a Navigable tree. In other words,
Hibernate
> defines a common visitor for how to walk the application's
mapped domain
> model and the NavigableVisitationStrategy implementation
controls which
> sub-trees are walked; e.g. we'd use this to apply JPA
EntityGraphs or to
> stop joining joinable Navigables after we have reached the
> `max_fetch_depth` setting value.
>
> It is important to note that this is very, very different from
JPA's model
> and walking it. JPA's model essentially precludes those model
nodes from
> defining relational mappings as part of its type system in any
sane way;
> this is due to various reasons because of the model's
design[2]. This
> Navigable walking would walk the real/full relational mapping model.
>
> The design question is whether we want to expose this "domain
mode walking"
> as a general public API feature. This has been requested
before; Max once
> asked for it although I forget why.
>
> Making this an API means exposing quite a few things. Typical
visitor
> pattern, the visitor (NavigableVisitationStrategy) exposes
"handle" methods
> based on specific Navigable sub-types. Those sub-types would
need to be
> moved to API. I don't have a particular concern with that, just
mentioning
> it.
>
> Opinions on whether this should become an API?
>
> For sure we'd mark it @Incubating, if we decide to do it.
>
> [1] Short synopsis: Navigables include things like EntityPersister,
> CollectionPersister, EmbeddedPersister, PersistentAttribute,
> CollectionIndex, CollectionElement. A Navigable is always
relative to a
> NaviagbleSource. NaviagbleSources are any domain Navigable
> (NavigableSource extends Navigable) which includes things like
> EntityPersister, EmbeddedPersister, SingularPersistentAttribute,
> CollectionElementEntity, CollectionElementEmbedded, etc . The
> NaviagbleSource will be null in the case of EntityPersister (as
a root),
> but in all other cases the NaviagbleSource is non-null.
>
> [2] I won't get into the reasons here, but we can certainly
follow up if
> anyone challenges that assertion.
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
>
https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org <mailto:hibernate-dev@lists.jboss.org>
https://lists.jboss.org/mailman/listinfo/hibernate-dev