HHH-20006 uniqueElement() did not have a self-consistent definition of "same"

[gavinking]

Really, getSingleResult() is saying there should be a single element in getResultList(). If that's not the case, you should use select distinct.

That said, we might want a way to recover the old behavior (H5, apparently) of making things distinct in memory according to equals(). Though, actually, I believe you can just use a ResultListTransformer for that. Perhaps we should just add a built-in one for migration purposes.

[Please describe here what your change is about]

---

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.

---

https://hibernate.atlassian.net/browse/HHH-20006

[gavinking]

@sebersole WDYT of this?

[beikov]

I think this is a good change, but depending on what the behavior of ORM 5.x was, we might want to either backport this or add a migration guide note.

Imagine what would happen if you do e.g. select e.someIntField from MyEntity e and call getSingleResult(). This would have succeeded if all values are the same with ORM 6.x and 7.x, but now start to fail. Not saying that such errors would be wrong, just that we have to be careful.

[gavinking]

Imagine what would happen if you do e.g. select e.someIntField from MyEntity e and call getSingleResult(). This would have succeeded if all values are the same with ORM 6.x and 7.x, but now start to fail. Not saying that such errors would be wrong, just that we have to be careful.

The trouble is that right now this can succeed or fail depending on the JDBC driver. On h2, I got Integer values being canonicalized, and passing, but on Postgres the same code failed. Pretty ugly.

[gavinking]

add a migration guide note.

We definitely need to do that. For sure.