Missing GROUP BYs in keyset pagination queries with blaze 1.6.9 and Hibernate 6.2.7 but not with Hibernate 5

[famod]

Hi everyone!

@mickroll and I are currently migrating our Quarkus + BlazePersistence + Hibernate App to Quarkus 3/Hibernate 6 and we have a strange issue with our keyset pagination queries.

We don't see any "group by" clauses anymore in the statements that are logged by Hibernate.
We expect blaze to auto-add all relevant group bys which doesn't happen anymore (or they are swallowed in Hibernate).
Even the one explicit query.groupBy("id") we have in our code doesn't manifest itself anymore in the actual queries.

It's interesting that our current productive Quarkus2/Hibernate 5 app is already using the same BlazePersistence version 1.6.9 so it seems it's either an issue in the blaze integration module for Hibernate 6 or in Hibernate 6 itself?

Any hints? Thanks!

PS: Sorry for the low level of details. I'm a bit in a rush but I can try to add more details later - please let me know what you need.

[famod]

Um, I found the fix: we have to change query.groupBy("id") to query.groupBy("id.id").

In that Q3 migration branch we also migrated our strongly typed id classes (which we call DomainIdentifers, e.g. FruitId wrapping a UUID, instead of a plain UUID field in Fruit) from a deeper custom Hibernate AbstractSingleColumnStandardBasicType integration approach to a plain JPA @EmbeddedId approach. In both cases you then do have a "physical" path of <someEntity>.id.id to get to the UUID, but with that older, deeper integrated BasicType approach the mapping for Hibernate is more direct.
With that @EmbeddedId setup, blaze is doing some field name splitting magic and ends up dropping the group by silently (AbstractCommonQueryBuilder.applyExpressionTransformersAndBuildGroupByClauses(JoinVisitor) -> groupByManager.collectGroupByClauses(joinVisitor) -> ... -> EmbeddableSplittingVisitor).
This (apparently) also causes the absence of all other group by columns in the query.

At this point I have two questions/remarks:

• Is it expected that you have to define the fully expanded path of such an embedded id? Does that mean that if you have more than one field in that id wrapper you need to pass all of them to groupBy?
• I find it a bit irritating that a user defined groupBy is dropped silently like this. I find this very dodgy, but then again I might be missing cases where this behaviour is desirable.

[beikov]

Hi Falko,

Is it expected that you have to define the fully expanded path of such an embedded id? Does that mean that if you have more than one field in that id wrapper you need to pass all of them to groupBy?

No it's not expected. The EmbeddableSplittingVisitor should actually take care of this, but maybe there is a bug. Would very much appreciate a reproducer :)

I find it a bit irritating that a user defined groupBy is dropped silently like this. I find this very dodgy, but then again I might be missing cases where this behaviour is desirable.

Since I don't see the full query that you are working with, I'm having a hard time understanding where this could go wrong. The user defined group by items should never be dropped AFAICT, but if the embeddable splitting has a bug, then this could happen.

[famod]

Hi Christian and thanks for your reply!

I'll try to provide a reproducer in the next two weeks or so. At this point I'm assuming that I don't even need a more sophisticated keyset pagination example - a dead simple select with a group by should do.

[famod]

@beikov please see #1775, thanks!