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 https://lists.jboss.org/mailman/listinfo/hibernate-dev

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 > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev

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(a)lists.jboss.org&gt; > > 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev(a)lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev