Submitted a third time to make clear the purpose
> Hi all,
> 
> This replaces my earlier messages on this thread with one that starts from 
> the background.
> 
> Aliases in GORM criteria
> 
> A criteria query can reach an association in two ways: an alias, 
> createAlias('scores', 'a'), which names a join so a restriction can say 
> a.round, or a block, scores { eq('round', 'first') }. Each one is a join of 
> the association. The open question is what a query means when it uses 
> several. Take an owner with a score in round one and another in round two:
> 
>     Pet.withCriteria {
>         owner { scores { eq('round', 'first') } }
>         owner { scores { eq('round', 'second') } }
>     }
> 
> If the two blocks share a join, one score has to be in both rounds, so no pet 
> matches. If each has its own join, the pet matches. Several open PRs 
> disagreed on this, and on a related point: when an association has several 
> aliases, which join an order by scores.score sorts by.
> 
> Why Hibernate 5 could not settle it
> 
> For the same criteria, Hibernate 5 can return different rows depending on 
> statement order, or on whether the criteria runs at the top or inside a 
> subquery. In the combinations we tested it throws for 71% and contradicts 
> itself for 7%, so it cannot be the reference. Separately, a DetachedCriteria 
> dropped the first alias when a second was declared for one association 
> (#16851).
> 
> The rule, decided in https://github.com/apache/grails-core/issues/16889
> 
> Blocks without an alias share one join, as in Hibernate 5. The first alias of 
> an association path shares it, and every later alias has its own join, in the 
> same block or another. An order by a path in a block that declares an alias 
> for it sorts by that alias. To ask for two different elements, use two 
> aliases.
> 
> The PRs
> 
> #16773, #16866, #16863 and #16559 overlapped in the same files, so they are 
> consolidated with every author's commits kept through merge commits:
> 
> - https://github.com/apache/grails-core/pull/16891 : Hibernate 7 on 8.0.x, 
> with the rule, its tests and the documentation. CI is running.
> - https://github.com/apache/grails-core/pull/16890 : the shared core part on 
> 7.0.x, which merges first. It is opt-in per datastore, so Mongo, Neo4j and 
> the simple datastore behave as before.
> 
> #16853 (the Hibernate 5 sort) stays on its own. The original PRs stay open 
> until these are reviewed. The datamapping-core, Hibernate 5 and Hibernate 7 
> suites and the style checks pass locally on both branches.
> 
> Please review #16891 and #16890, and tell me if the rule in #16889 is wrong 
> for you.
> 
> Walter

Reply via email to