Re: [hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy
Ok, thanks! On Tue, Sep 3, 2019 at 6:01 AM Steve Ebersole wrote: > We do not support an application implementing a custom > PersistenceContext. > > I'm not against adding a default, but most likely that default would be a > "throw an exception" type which I am not sure is useful > > On Mon, Sep 2, 2019 at 4:19 PM Gail Badner wrote: > >> HHH-11147 added PersistenceContext#addEnhancedProxy without a default >> implementation. >> >> Would an application implement PersistenceContext? If so, this would be a >> breaking change. >> >> Please let me know... >> >> Thanks, >> Gail >> ___ >> 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] EntityMetamodel
Ok, thanks. On Tue, Sep 3, 2019 at 6:09 AM Steve Ebersole wrote: > Seems like we dropped the need for the subclass checking here but did not > remove passing that Function. Technically it could be removed and the > EntityMetamodel > constructor reverted > > On Mon, Sep 2, 2019 at 9:14 PM Gail Badner wrote: > >> HHH-11147 changed a EntityMetamodel constructor argument from >> a SessionFactoryImplementor to a PersisterCreationContext. >> >> Would a custom EntityPersister break due to calling the constructor with >> the new argument type? >> >> From what I can tell, the argument was changed to >> PersisterCreationContext go get access to an entity's metamodel, intended >> to be used by EnhancementHelper.includeInBaseFetchGroup. >> >> The Function subclassChecker is passed to: >> * BytecodeEnhancementMetadataPojoImpl.from >> * LazyAttributesMetadata.from >> * EnhancementHelper.includeInBaseFetchGroup >> >> EnhancementHelper.includeInBaseFetchGroup does not use the value passed >> in for hasSubclassChecker. >> >> Can the EntityMetamodel constructor be changed back to take a >> SessionFactoryImplementor? >> >> Can the hasSubclassChecker argument be removed from >> BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and >> EnhancementHelper.includeInBaseFetchGroup? >> >> Thanks, >> Gail >> > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] EntityMetamodel
Seems like we dropped the need for the subclass checking here but did not remove passing that Function. Technically it could be removed and the EntityMetamodel constructor reverted On Mon, Sep 2, 2019 at 9:14 PM Gail Badner wrote: > HHH-11147 changed a EntityMetamodel constructor argument from > a SessionFactoryImplementor to a PersisterCreationContext. > > Would a custom EntityPersister break due to calling the constructor with > the new argument type? > > From what I can tell, the argument was changed to PersisterCreationContext > go get access to an entity's metamodel, intended to be used > by EnhancementHelper.includeInBaseFetchGroup. > > The Function subclassChecker is passed to: > * BytecodeEnhancementMetadataPojoImpl.from > * LazyAttributesMetadata.from > * EnhancementHelper.includeInBaseFetchGroup > > EnhancementHelper.includeInBaseFetchGroup does not use the value passed in > for hasSubclassChecker. > > Can the EntityMetamodel constructor be changed back to take a > SessionFactoryImplementor? > > Can the hasSubclassChecker argument be removed from > BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and > EnhancementHelper.includeInBaseFetchGroup? > > Thanks, > Gail > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] Property#isLazy
Do you have an example where this is actually a problem? On Mon, Sep 2, 2019 at 8:01 PM Gail Badner wrote: > HHH-11147 changed Property#isLazy as shown in [1]. > > The part that concerns me is: > > + // For a many-to-one, this is always false. Whether the > + // association is EAGER, PROXY or NO-PROXY we want the fk > + // selected > + return false; > > I don't think this is correct when enhancement-as-proxy is disabled. > > Join#isLazy relies on Property#isLazy for the properties included in the > Join. > > If Join#isLazy is returning the wrong value, > then SingleTableEntityPersister#isSubclassTableLazy > and JoinedSubclassEntityPersister#isSubclassTableLazy will return the wrong > value. > > Steve, WDYT? > > Thanks, > Gail > > [1] > https://github.com/hibernate/hibernate-orm/commit/cc01f2561dbca95bd58048f85e283ba1719ee588#diff-f564326e8dae92695cdffe6509fb8f0b > > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] No default implementation for PersistenceContext#addEnhancedProxy
We do not support an application implementing a custom PersistenceContext. I'm not against adding a default, but most likely that default would be a "throw an exception" type which I am not sure is useful On Mon, Sep 2, 2019 at 4:19 PM Gail Badner wrote: > HHH-11147 added PersistenceContext#addEnhancedProxy without a default > implementation. > > Would an application implement PersistenceContext? If so, this would be a > breaking change. > > Please let me know... > > Thanks, > Gail > ___ > 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
