How are sub entities de-duped in an entity view that generates a query with joins in?

[re1709]

I'm creating an entity view for a class BookHolder which has a basic id field, plus three lists of sub entities (each using a respective view) - rules, captures and books.

The database for BookHolder with id 1 has:

• 1 capture with id 2
• 1 rule with id 3
• 2 books with id 4 and 5

The BookHolderView comes back with the id, 1 rule (id 3), 2 books (id 4 and 5) but 2 captures (both id 2 - so clearly duplicates).

When i remove the books from the view, only 1 capture comes back. So my understanding is that the join in the query is causing duplicate rows. However Blaze must be attempting to de-duplicate here, as only 1 rule comes back in the final view - which is correct.

I'm guessing that the configuation of the Capture entity is causing an issue with the de-duplication. Unfortunately i'm not able to share code at this point, but we have checked the entity and there is nothing obvious that stands out (e.g. a json converter) that are being used compared to the Rule entity.

I've tried generating a proper equals and hashcode generated by JPA buddy, but this had no effect. I'm just curious to how Blaze de-duplicates Sub Entity Views when using a join fetched strategy, as this might shed some light on why the Capture is duplicated.

I'm aware of using a sub select strategy and this does work, however it is concerning we have a bug somewhere in our code for Rules to not being duplicated but Captures are when using a join fetch strategy.

Thanks in advance!

[beikov]

Hi,
AFAIR, Blaze-Persistence does not attempt to de-duplicate elements of non-indexed collections. You can debug the implementation com.blazebit.persistence.view.impl.objectbuilder.transformer.NonIndexedTupleListTransformer.

Maybe one of your lists has an index column in the entity model i.e. @OrderColumn? The presence of that makes it an indexed list which is de-duplicated since the index provides row identity.

I would recommend you to mostly use a Set instead or SortedSet if you want a particular ordering. If the order of the elements matters to you, you should always use an @OrderColumn in your entity mapping.

[re1709]

Thanks that's exactly what's happening. One of the lists does have an index column (@OrderColumn) and the other does not. The list without we don't care about the order and there will never be duplicate entities (it should be a Set like you say really....).

I'm happy to use a sub select strategy on this list to avoid the duplicates, but going by the docs we could use a Set on the blaze view (but keep the entity as a list for now - some code would need refactoring etc to change the entity) and this would also work ok with the default join fetch strategy?

[beikov]

Correct, you can use a Set in the entity view even though you use a List on the entity side.