Re: [hibernate-dev] Hibernate#isPropertyInitialized vs Hibernate#isInitialized

[Steve Ebersole]

Your subject says `Hibernate#isInitialized` but then your examples refer to
`Hibernate#initialize`.  Which are your referring to?  Because in some
cases you genuinely seem to be referring to `#initialize`, but then you
keep referring to its return value - `#initialize` has no return.


On Thu, Mar 9, 2017 at 12:27 AM Gail Badner  wrote:

> I think there can be an inconsistency between
> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
> an extra-lazy collection of an enhanced entity.
>
> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
> on an enhanced entity, the collection property is set to an uninitialized
> PersistentCollection and calling Hibernate#isPropertyInitialized(
> collectionfieldName ) will return true, even though the collection itself
> is uninitialized.
>
> I would have expected that false would be returned.
>
> I've added a comment to the issue and asked Luis about it. Luis has pointed
> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
> listed them below and added my understanding of what Hibernate#initialize
> and Hibernate#isPropertyInitialized will return in each instance:
>
> 1) the attribute is not loaded at all;
> Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns false;
> Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> false; a side-affect
> is that the attribute will be set to an uninitialized
> PersistentCollection.
> 2) the attribute is loaded, but the elements are not loaded;
> Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns true,
> because the property is initialized to a PersistentCollection (even
> though the PersistentCollection itself is uninitialized).
>   Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> false.
> 3) the attribute is loaded and the elements are loaded.
>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
> returns true.
>   Hibernate.initialize( enhancedEntity.getExtraLazyCollection() ) returns
> true.
>
> Opinions about the inconsistency in 2)? Is this a bug in the code or in the
> Javadoc?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-11161
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

[hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

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

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

[Alessio Stalla]

Well, as the developer of a framework that uses Hibernate for persistence,
I say yes to more introspection APIs :)

On 9 March 2017 at 17:35, Steve Ebersole  wrote:

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

Re: [hibernate-dev] Hibernate#isPropertyInitialized vs Hibernate#isInitialized

[Gail Badner]

Oops, sorry for the confusion. They should have referred to
Hibernate#isInitialized.

I'll fix and clarify below...

On Thu, Mar 9, 2017 at 4:58 AM, Steve Ebersole  wrote:

> Your subject says `Hibernate#isInitialized` but then your examples refer
> to `Hibernate#initialize`.  Which are your referring to?  Because in some
> cases you genuinely seem to be referring to `#initialize`, but then you
> keep referring to its return value - `#initialize` has no return.
>
>
> On Thu, Mar 9, 2017 at 12:27 AM Gail Badner  wrote:
>
>> I think there can be an inconsistency between
>> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes
>> to
>> an extra-lazy collection of an enhanced entity.
>>
>> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
>> on an enhanced entity, the collection property is set to an uninitialized
>> PersistentCollection and calling Hibernate#isPropertyInitialized(
>> collectionfieldName ) will return true, even though the collection itself
>> is uninitialized.
>>
>> I would have expected that false would be returned.
>>
>> I've added a comment to the issue and asked Luis about it. Luis has
>> pointed
>> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
>> listed them below and added my understanding of what
>> Hibernate#isInitialized
>> and Hibernate#isPropertyInitialized will return in each instance:
>>
>> 1) the attribute is not loaded at all;
>> Hibernate.isPropertyInitialized( enhancedEntity,
>> "extraLazyCollection" )
>> returns false;
>> (I am skipping an example of calling Hibernate.isInitialized(
>> enhancedEntity.getExtraLazyCollection() )
>>
>here because by calling enhancedEntity.getExtraLazyCollection(),
the property becomes initalized
   with an uninitialized PersistentCollection, so it will be in the
state described as 2).


> 2) the attribute is loaded, but the elements are not loaded;
>> Hibernate.isPropertyInitialized( enhancedEntity,
>> "extraLazyCollection" )
>> returns true,
>> because the property is initialized to a PersistentCollection (even
>> though the PersistentCollection itself is uninitialized).
>>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
>> returns
>> false.
>>
>

> 3) the attribute is loaded and the elements are loaded.
>>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
>> )
>> returns true.
>>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
>> returns
>> true.
>>
>> Opinions about the inconsistency in 2)? Is this a bug in the code or in
>> the
>> Javadoc?
>>
>> Thanks,
>> Gail
>>
>> [1] https://hibernate.atlassian.net/browse/HHH-11161
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Hibernate#isPropertyInitialized vs Hibernate#isInitialized

[Steve Ebersole]

Maybe this helps:

   1. the attribute is not loaded at all (no PersistentCollection creation)
   1. Hibernate.isPropertyInitialized( enhancedEntity,
  "extraLazyCollection" ) -> returns false
  2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
  -> irrelevant, the getExtraLazyCollection() call leads to creation of the
  PersistentCollection (see 2.2)
  2. the attribute is loaded, but the elements are not loaded
   1. Hibernate.isPropertyInitialized( enhancedEntity,
  "extraLazyCollection" ) -> returns true
  2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
  -> returns false
   3. the attribute is loaded and the elements are loaded
   1. Hibernate.isPropertyInitialized( enhancedEntity,
  "extraLazyCollection" ) -> returns true
  2. Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
  -> returns true

IIUC you are asking whether 2.1 returning true is conceptually accurate.
Yes?

Perhaps we want to distinguish between initialized and loaded?  I think
that is generally applicable.

On Thu, Mar 9, 2017 at 11:55 AM Gail Badner  wrote:

> Oops, sorry for the confusion. They should have referred to
> Hibernate#isInitialized.
>
> I'll fix and clarify below...
>
> On Thu, Mar 9, 2017 at 4:58 AM, Steve Ebersole 
> wrote:
>
> Your subject says `Hibernate#isInitialized` but then your examples refer
> to `Hibernate#initialize`.  Which are your referring to?  Because in some
> cases you genuinely seem to be referring to `#initialize`, but then you
> keep referring to its return value - `#initialize` has no return.
>
>
> On Thu, Mar 9, 2017 at 12:27 AM Gail Badner  wrote:
>
> I think there can be an inconsistency between
> Hibernate#isPropertyInitialized vs Hibernate#isInitialized when it comes to
> an extra-lazy collection of an enhanced entity.
>
> IIUC, after fixing HHH-11161 [1], if an extra-lazy collection is accessed
> on an enhanced entity, the collection property is set to an uninitialized
> PersistentCollection and calling Hibernate#isPropertyInitialized(
> collectionfieldName ) will return true, even though the collection itself
> is uninitialized.
>
> I would have expected that false would be returned.
>
> I've added a comment to the issue and asked Luis about it. Luis has pointed
> out the 3 stages of an extra-lazy collection on an enhanced entity. I've
>
> listed them below and added my understanding of what
> Hibernate#isInitialized
>
>
> and Hibernate#isPropertyInitialized will return in each instance:
>
> 1) the attribute is not loaded at all;
> Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns false;
>
> (I am skipping an example of calling Hibernate.isInitialized(
> enhancedEntity.getExtraLazyCollection() )
>
>here because by calling
> enhancedEntity.getExtraLazyCollection(), the property becomes initalized
>with an uninitialized PersistentCollection, so it will be in
> the state described as 2).
>
>
> 2) the attribute is loaded, but the elements are not loaded;
> Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection"
> )
> returns true,
> because the property is initialized to a PersistentCollection (even
> though the PersistentCollection itself is uninitialized).
>
>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
> returns
> false.
>
>
>
> 3) the attribute is loaded and the elements are loaded.
>   Hibernate.isPropertyInitialized( enhancedEntity, "extraLazyCollection" )
> returns true.
>
>   Hibernate.isInitialized( enhancedEntity.getExtraLazyCollection() )
> returns
>
>
> true.
>
> Opinions about the inconsistency in 2)? Is this a bug in the code or in the
> Javadoc?
>
> Thanks,
> Gail
>
> [1] https://hibernate.atlassian.net/browse/HHH-11161
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

[Christian Beikov]

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

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

[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 
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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] 6.0 - design question: "model navigation" exposed as an API?

[Christian Beikov]

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 
> mailto:christian.bei...@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@lists.jboss.org 
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org 
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev