jdaugherty commented on code in PR #16505:
URL: https://github.com/apache/grails-core/pull/16505#discussion_r4178509364
##########
grails-data-hibernate7/core/src/main/groovy/grails/orm/HibernateCriteriaBuilder.java:
##########
@@ -1112,6 +1115,46 @@ public Criteria sizeLt(String propertyName, int size) {
return this;
}
+ /**
+ * Builds a junction, whose block {@link DetachedCriteria} resolves its
calls against, with
+ * {@code sqlRestriction} added to the detached criteria of the block and
of the association blocks inside it.
+ */
+ private void inJunction(Runnable junction) {
+ GroovyCategorySupport.use(SqlRestrictionCategory.class, new
Closure<Object>(this) {
Review Comment:
Fixed in c316b7d52c. `SqlRestrictionCategory` is now
`HibernateDetachedCriteriaExtension`, registered in
`META-INF/services/org.codehaus.groovy.runtime.ExtensionModule`, and the
builder's `and`, `or` and `not` call `hibernateQuery` directly again, so no
query enters a category scope. The switch point stays valid after an `or`
query, and the 300 call sites take about 60 µs after both plain and `or`
queries.
`sqlRestriction` now also works on a detached criteria, including one used
as a subquery, where `{alias}` stands for the subquery's table. `criteria.adoc`
and `detachedCriteria.adoc` document it, and
`HibernateCriteriaBuilderSqlRestrictionSpec` covers it, along with a check that
no category is active inside a junction. `updateAll` and `deleteAll` on such a
criteria throw, because `JpaQueryBuilder` has no handler for `SqlRestriction`.
The batch-operations note documents that, and a test covers it.
Verified on JDK 21: `HibernateCriteriaBuilderSqlRestrictionSpec`,
`HibernateCriteriaBuilderSpec`, `HibernateCriteriaBuilderDirectSpec`,
`CriteriaMethodInvokerSpec`, `PredicateGeneratorSpec` and
`JpaCriteriaQueryCreatorSpec` pass on H2, and `SqlRestrictionHibernate7Spec`
passes on all five databases.
##########
grails-data-hibernate7/core/src/main/groovy/grails/orm/HibernateCriteriaBuilder.java:
##########
@@ -1112,6 +1113,32 @@ public Criteria sizeLt(String propertyName, int size) {
return this;
}
+ /**
+ * Restricts the results with a native SQL condition. {@code {alias}} in
the SQL stands for the table alias of
+ * the queried entity.
+ *
+ * @param sqlRestriction the SQL condition
+ * @return this criteria
+ */
+ public org.grails.datastore.mapping.query.api.Criteria
sqlRestriction(String sqlRestriction) {
+ return sqlRestriction(sqlRestriction, Collections.emptyList());
+ }
+
+ /**
+ * Restricts the results with a native SQL condition whose {@code ?}
placeholders are bound to the given values.
+ * {@code {alias}} in the SQL stands for the table alias of the queried
entity.
+ *
+ * @param sqlRestriction the SQL condition
+ * @param values the values of the {@code ?} placeholders, in order, none
of them {@code null}
+ * @return this criteria
+ * @throws IllegalArgumentException if the number of {@code ?}
placeholders differs from the number of values,
+ * or a value is {@code null}
+ */
+ public org.grails.datastore.mapping.query.api.Criteria
sqlRestriction(String sqlRestriction, List<?> values) {
+ hibernateQuery.add(new SqlRestriction(sqlRestriction, values));
Review Comment:
Follow-up: c316b7d52c replaces the Groovy category scope described above,
because entering and leaving a category invalidates the call sites of every
thread on each junction. `sqlRestriction` is now a Groovy extension method on
`AbstractDetachedCriteria`, so it still lands on whichever criteria is the
active delegate: the junction itself, an association block inside it, a
junction inside that association, or a nested association. The
association-in-junction regressions listed above pass unchanged.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
