8.x Register CriteriaTypeCheckingExtension and cover createCriteria().<terminal>{} closures#15720
8.x Register CriteriaTypeCheckingExtension and cover createCriteria().<terminal>{} closures#15720codeconsole wants to merge 2 commits into
Conversation
…rminal>{} closures
CriteriaTypeCheckingExtension existed but was never added to the
@GrailsCompileStatic extension list, and isCriteriaCall only recognized the
Domain.withCriteria {} / Domain.createCriteria() forms where the closure is
the direct argument. The chained Domain.createCriteria().<terminal> { } form
(closure as the argument to a terminal called on the builder) was not
matched, so its scope was never opened.
Most chained terminals (list/listDistinct/get/scroll) still type-checked
because BuildableCriteria declares them with a Closure parameter and
@DelegatesTo resolves the closure body. count(Closure) is not declared on
BuildableCriteria, so Domain.createCriteria().count {} failed static
compilation with 'Cannot find matching method BuildableCriteria#count(Closure)'.
Extend isCriteriaCall to also open a criteria scope for a terminal
(list/listDistinct/get/count/scroll) chained directly on createCriteria(),
and register the extension in @GrailsCompileStatic so criteria-builder
closures type-check under static compilation. Adds a test covering all six
chained terminals; count is the case that fails without this change.
git log --oneline -1
Codecov Report❌ Patch coverage is
Additional details and impacted files@@ Coverage Diff @@
## 8.0.x #15720 +/- ##
==================================================
+ Coverage 48.3483% 48.3627% +0.0144%
- Complexity 15104 15233 +129
==================================================
Files 1870 1877 +7
Lines 85459 85905 +446
Branches 14901 14974 +73
==================================================
+ Hits 41318 41546 +228
- Misses 37805 37986 +181
- Partials 6336 6373 +37
🚀 New features to boost your workflow:
|
| 'org.grails.compiler.WhereQueryTypeCheckingExtension', | ||
| 'org.grails.compiler.DynamicFinderTypeCheckingExtension', | ||
| 'org.grails.compiler.DomainMappingTypeCheckingExtension', | ||
| 'org.grails.compiler.CriteriaTypeCheckingExtension', |
There was a problem hiding this comment.
To change the default, we need to expand the test coverage so that there are tests in the TCK - this way we know we haven't broken it in hibernate 7.
There was a problem hiding this comment.
Added in b10f36f. The TCK now executes criteria queries that were compiled with @GrailsCompileStatic, covering both dispatch paths the extension produces: statically-resolved Criteria API calls and the dynamic fallback (projections, min/countDistinct/property, maxResults, and the chained count { } terminal, which is not declared on BuildableCriteria). Verified green against the in-memory, Hibernate 5, Hibernate 7, and MongoDB implementations locally.
|
The pull request already includes a new test case, 'Test compiling a class which invokes a chained createCriteria() terminal on a domain class', within grails-test-suite-uber/src/test/groovy/grails/compiler/GrailsCompileStaticCompilationErrorsSpec.groovy |
Registering CriteriaTypeCheckingExtension changes the default compile semantics of every @GrailsCompileStatic class, so the TCK now runs criteria queries that were compiled statically against each GORM implementation. The queries mix calls that resolve statically against the Criteria API (eq, like, or, order) with calls that only compile through the extension's dynamic-dispatch fallback (projections, min, countDistinct, property, maxResults and the count terminal chained on createCriteria(), which is not declared on BuildableCriteria), proving that dispatch behaves identically to dynamic Groovy on the in-memory, Hibernate 5, Hibernate 7 and MongoDB implementations.
✅ All tests passed ✅Test Summary
🏷️ Commit: b10f36f Learn more about TestLens at testlens.app. |
What
CriteriaTypeCheckingExtensionexists in grails-core but is not registered in@GrailsCompileStatic's extension list, andisCriteriaCallonly recognizes theDomain.withCriteria { … }/Domain.createCriteria()forms (closure as the direct argument). The chainedDomain.createCriteria().<terminal> { … }form — where the closure is the argument to a terminal called on the builder — is never matched, so a criteria scope is never opened for it.Why it matters
Most chained terminals (
list,listDistinct,get,scroll) still type-check today becauseBuildableCriteriadeclares them with aClosureparameter and@DelegatesToresolves the closure body. Butcount(Closure)is not declared onBuildableCriteria, so:fails static compilation on stock 8.0.x:
forcing a
@CompileDynamicescape hatch.Change
isCriteriaCallto also open a criteria scope when the call is a terminal (list,listDistinct,get,count,scroll) chained directly onDomain.createCriteria(). Registration alone is not enough — thecreateCriteria()scope is exited (viaafterMethodCall) before the terminal call is visited, so the terminal needs to be recognized in its own right.org.grails.compiler.CriteriaTypeCheckingExtensionto the@CompileStatic(extensions=[…])list on@GrailsCompileStatic.Test
Adds
'Test compiling a class which invokes a chained createCriteria() terminal on a domain class'toGrailsCompileStaticCompilationErrorsSpec, covering all six chained terminals. It fails on stock 8.0.x (on thecountterminal) and passes with this change. The existingGRAILS-11255criteria spec continues to pass.Scope / limits
The extension makes the direct children of the criteria closure dynamic. Deeply nested builder closures (e.g.
projections { property '…' }) and post-processing that indexes the result (withCriteria { … }[0]) still require@CompileDynamic— out of scope here.