Fails with the following exception:
Note the where clause mentioned in the exception: where generatedAlias0.id as x=:id.
This happens only in 5.4.1-SNAPSHOT; 5.4.0.Final seems to be fine.
As spotted by , the issue comes from https://github.com/hibernate/hibernate-orm/pull/2676 .
The added alias is a component of the path itself and there is a cache for the paths so you end up having the alias set in all the paths using the same attribute name.
Adding a condition in render() is not sufficient as it's not really feasible IMHO to know if we are at the root of the select (e.g. what if you're in a function? we have a function stack but it looks like it's not properly implemented everywhere, typically it does not seem our aggregation functions add elements to the function stack). And I suppose it's possible to define custom functions.
I think we should probably revert the patch for now and maybe revisit this in 6 if there's a better way of doing that.
Most likely we need to apply the same approach we used for LiteralExpression so that we have a separate renderProjection which applies this change. I could take a look at it.
That was my first instinct, I ended up with:
The test passes with that, obviously.
But as I said, I don't think it's solid enough: it's different from the literal case as it's not only "it has to be in the SELECT clause" but "it has to be at the root at the SELECT clause". Typically, if you have AVG(name) in your SELECT clause, you don't want the alias to be expanded for name.
I foresee quite a lot of corner cases unfortunately and I don't think the "bugfix/improvement" is worth the risk in a x.x.1.
Might be a good idea to think about what we would need in 6 to implement this thing properly.