I do agree that in most cases one would use a distinct query and the non-distinct behaviour is usually not what one wants to use. But still, if one decides to use distinct=false, it should work correctly and conform to the JPA specification, which explicitely states that no de-duplication is performed as quoted above.

The most practical example where the current behaviour breaks applications i can give is the Spring Data JPA’s paging:

E.g. for page size 10, a query with {{limit 10}}is executed. SQL will only deliver 10 results, where some might be duplicates. Now hibernate de-duplicates the result, returning a list with size < 10. Because the page is not full, Spring Data assumes that this is the last page and therefore delivers wrong pageCount/total numbers. If the page did not contain duplicates and 10 unique elements are found, a count query is executed using the same filters. Now this count obviously counts all rows, including duplicates and hibernate cannot perform de-duplication - it’s just a number after all.

Instead of such weird behaviour, I’d rather have duplicates - which is also what i can expect and explain looking at the JPA spec and the plain SQL results.

Additionally, I did not find a way to change the uniqueSemantic via JPA, only via hibernate specific APIs, so implementations which stick to JPA cannot turn off this behaviour.

I did not yet test with other JPA implementations, however looking at the information you provided I assume this is a Hibernate specific implementation detail.