As a result of fixing HHH-12436
<https://hibernate.atlassian.net/browse/HHH-12436>, some eager *-to-one
associations that were loaded using FetchMode.JOIN may instead be loaded
using FetchMode.SELECT, and vice-versa. In some cases, @NotFound behavior
is different depending on the FetchMode for the association.
The reason why FetchMode may change due to HHH-12436
<https://hibernate.atlassian.net/browse/HHH-12436> is that the
ForeignKeyDirection of some *-to-one associations were incorrect.
Correcting the ForeignKeyDirection will result in a different
AssociationKey, which may ultimately affect the FetchMode Hibernate assigns
to an association.
My hope is to resolve the inconsistencies before fixing HHH-12436
<https://hibernate.atlassian.net/browse/HHH-12436>, so it does not result
in a change in application behavior.
I've created a Google Doc to document the inconsistencies and to make it
easier to discuss how to go about resolving them:
Please feel free to request access to the document if you wish to review or
HHH-11209 involves a bug merging a detached entity with an uninitialized
collection that has queued operations.
After looking into this issue I found a bug
where AbstractPersistentCollection#operationQueue was not being cleared
after a commit, if there was no cascade mapped for the collection.
I've fixed that in a PR. 
After that fix, the detached entity in the test case attached to HHH-11209
has an uninitialized entity without any queued operations after commit,
which can be merged successfully in a new session/transaction.
There is still a problem when Hibernate tries to merge a detached entity
has an uninitialized collection with queued operations though. My PR throws
UnsupportedOperationException in this case, and there is a test case that
I've been working on a fix to add support for this, but I have my doubts
that it really should be supported. I see that prior to fixing HHH-5855
(which caused HHH-11209), Hibernate simply ignored the queued operations in
the detached collection. .
The fix for HHH-5855 properly dealt with merging a managed collection that
was uninitialized with queued operations. It introduced the bug where a
NullPointerException would get thrown if that collection was detached.
If we want to support merging the queued operations, then I would consider
that an improvement. Would this be a worthwhile improvement? I'm guessing
not, but I wanted to get some opinions.
For now, I see a couple of ways to deal with this so that HHH-11209 can be
1) ignore queued operations in a detached collection when merging, as was
done before HHH-5855 was fixed.
2) clear the queued operations when the collection is detached.
FYI, I just revoked all the legacy Jenkins API tokens, as recommended.
Don't worry, I'm talking about tokens issued by Jenkins to each user and
allowing to use Jenkins APIs; this is completely unrelated to GitHub/AWS
credentials and such.
More information: https://jenkins.io/blog/2018/07/02/new-api-token-system/
Apparently the tokens weren't being used by anyone, or at least haven't
been for a few weeks. But if you did need it, I guess you can always follow
the link above to find out how to use a new token.
Hibernate NoORM Team
While reviewing this Jira issue:
and further discussing it via Twitter, I wonder if we should persist
LocalTime as-is without any TimeZone transformation
that may be done if we enable `hibernate.jdbc.time_zone`?
According to the Date/Time API, LocalTime should not be relative to any
If we make this change, it means we need to use a LocalTime SQL descriptor
that ignores the jdbc.time_zone property,
and the change is going to break compatibility as well.