HHH-13317 is specifically a bug with bytecode enhancement using Javassist.
It showed up when running a test added for HHH-13241.
I've verified that the same issue affected 5.1, so this is not a regression.
Is it worthwhile to fix this issue in 5.3/5.4? Will Javassist continue to
be supported in Hibernate ORM 6? If not, I'd like to close HHH-13317 as
I've completed a rebase of Steve's latest ORM6 branch onto our latest ORM5
master, so to have it incorporate all latest bugfixes and performance
enhancements we recently developed on master.
To be more specific, this is a rebase of commit 'wip/sqm-jpa-types-sql-ast'
[2e002c73c6] onto 'master' [40b30fa099].
I'm pushing it as branch '6-rebased-August' to my own fork. (commit
I hope that anyone having some work in progress could cherry pick on top of
Also you probably want to push it somewhere else and give a more creative
Steve: the last commit might need special attention.
I needed to review the SessionImpl#buildLockOptions method as there was a
conflict, but while trying to resolve it I realized the method was probably
not doing what it was supposed to, so I changed it - I think fixing
something odd but I might have misunderstood the intent, or thrown off by
some mistake during rebase. Would appreciate another pair of eyes on that
one as I definitely changed the semantics.
HHH-11147 added PersistenceContext#addEnhancedProxy without a default
Would an application implement PersistenceContext? If so, this would be a
Please let me know...
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
The Function<String,Boolean> subclassChecker is passed to:
EnhancementHelper.includeInBaseFetchGroup does not use the value passed in
Can the EntityMetamodel constructor be changed back to take a
Can the hasSubclassChecker argument be removed from
BytecodeEnhancementMetadataPojoImpl.from, LazyAttributesMetadata.from, and
HHH-11147 changed Property#isLazy as shown in .
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
If Join#isLazy is returning the wrong value,
and JoinedSubclassEntityPersister#isSubclassTableLazy will return the wrong