Selection with criteria and entity graph updates data

Ever since [HHH-17690] was included we have some issues with data being updated when we do selection queries.

Case:

we have two entities A and B. They have a one to many relationship. When we select A based on a field in B with an entity graph that specifies it needs to fetch all B’s that are linked to A an instance of A will be returned with a list of B’s that only contains the B’s that matches the criteria. Continuing to work with this instance of A will result in updating te actual data and remove all other B’s that did not match the criteria from our database. This is a huge issue.

Currently we’ve downgrade to version 6.4.2 to avoid having this issue.

Can someone please take a look? Thank you.

1 Like

Please share the HQL you use and the produced SQL queries.

JPQL:
"SELECT a FROM A a JOIN a.bs b WHERE b.name = ?"

EntityGraph:

@NamedEntityGraph(
        name = "A.withBs",
        attributeNodes = {
                @NamedAttributeNode("bs")
        }
)

Produced Query:

SELECT a.id, b.id, b.a_id, b.name
FROM A a
INNER JOIN B b on b.a_id = a.id
WHERE b.name = ?

This will result in our managed entity having only the Bs that match that specific name.

Expected Query (before 6.4.3):

SELECT a.id, b1.id, b1.a_id, b1.name
FROM A a
INNER JOIN B b1 on b1.a_id = a.id
INNER JOIN B b2 on b2.a_id = a.id
WHERE b2.name = ?

This is indeed a bug. We should not reuse the same join if there are predicates involving that join alias. Please try to create a reproducer with our test case template and if you are able to reproduce the issue, create a bug ticket in our issue tracker and attach that reproducer.

The much better way to model this though is to use an exists predicate e.g.:

select a from A a where exists (select 1 from a.bs b where b.name = ?)

Indeed. But this behavior is exactly the opposite of what was said in [HHH-17690 ]. I think those changes just need to be reverted?

Simply reverting the fix is probably a bit too much. I would prefer to reuse joins if safely possible.

Hi, I’ve created [HHH-18378] - Hibernate JIRA to track this issue.

2 Likes

Thank you!

Does this mean that [HHH-17690 ] was not really a bug? I just want to avoid a back and forward of these “two bugs”. Because in the example of that ticket it also has a where cause on an entity that is specified in the entity graph as well (or am I missing something?).

@Steven_Mahieu older versions of Hibernate (5.x) probably always reused existing joins for entity fetches specified by graphs, so the existing issue reports were “correct” in highlighting a difference in behavior for Hibernate 6.x.

If the join alias of the HQL query is used in the where clause, though, it should never be reused since the results of the entity fetch graph would be affected, violating the contract and possibly causing problems when the association would be flushed. That’s why @beikov confirmed this is a bug, we should still try to optimize query by reusing joins when possible but if used in the where clause create two separate ones.