DATAJDBC-1953 Introduced DialectCriteriaCondition interface

[mipo256]

This PR addresses the following issue #1953.

The core of the problem, I think, is that we had the Comparator as a Java enum, which is not extendable. I thought that, from the future perspective, as @schauder pointed out, we cannot really foresee all the possible conditions that can be used. Arrays in PostgreSQL is just a very concrete case.

So, the issue that is pointed out by the author, I think, should be solved in the following way, from the API's perspective:

Criteria.where("tags").custom(() -> "@> ARRAY['electronics']::text[]");

and that would render to the SQL that we expect:

SELECT * FROM products WHERE tags @> ARRAY['electronics']::text[]

This approach allows users to customize the condition in any possible way for any given column. This is achieved by introducing the Comparator interface, rather than the Comparator enum.

P.S: I've tried to minimize the backwards incompatibility as much as possible, but still, some migration would be needed here. Therefore, I guess, we need to assign a breaking-change tag

[schauder]

Thanks for the contribution. We need a Developer Certificate of Origin (DCO) for new PRs.

For details about how and why see https://spring.io/blog/2025/01/06/hello-dco-goodbye-cla-simplifying-contributions-to-spring

[mipo256]

Hey @schauder, yeah, I am aware of this, I've added the sign off.

[mp911de]

I don't think this is a good design direction. We should have rather some way to express predicates in a way that allows to determine bindings, mapping of values and to generate SQL text. I'll leave some thoughts in the original ticket #1953

[mipo256]

Hey @mp911de, @schauder!

I've revisited the solution according to the comment left in here: #1953 (comment)

The usage sample for the issue looks like this:

where("foo").is("bar").and("baz").satisfies(Postgres.arrayContains("first", "second"))

This would render into the following:

foo = 'bar' AND baz @> ARRAY['first','second']::text[]

I've introduced a new interface - DialectCriteriaCondition, that represents a condition that would eventually render into the part of the SQL condition that is vendor specific.

Also, the API, as it is now created, allows users to define their own DialectCriteriaCondition, in case we do not have them yet, like this:

Criteria criteria = where("foo").satisfies(() -> "~* '*.example.*'"); // renders into foo ~* '*.example.*'

[mp911de]

This is a bit too little, especially given the later variant of concatenating values into SQL as it opens loopholes for SQL injection.

An operator should have a method accepting a MappingContext and likely a PersistentProperty that applies to it and an abstraction like R2DBC's BindMarkers. In return, we need a tuple of bind markers associated with their value and the SQL fragment. Maybe even a slimmer variant of BindTarget (without the binding identifier) would suit fit.

[mipo256]

@mp911de Am I correct that the desired interface signature should look like this:

public interface DialectCriteriaCondition {

   BindTarget render(MappingContext context, PersistentProperty property);
}

If so, then I have a couple of questions here:

1. Criteria API by itself is an open loophole to SQL injection, like it is how it is designed, since we're build query literally by concatinating values into SQL. Maybe if we're going to address this problem, then we can do it in a separate issue, what do you think?
2. The Criteria API is a top level API designed for end users, do we want to expose MappingContext, PersistentProperty an other abstraction? They are public, but it does not seem to be desirable to expose them to users.
3. What is the custom operator is not performed on a single PersistentProperty?

[mp911de]

1. I tend to disagree. Combinator and Comparator enums are closed types that do not allow for extensions. In return, Spring Data Relational controls what enum values are available to ensure we only specify safe operators. At some point, we have to translate criteria elements into a String. Specifically referring to the linked method, rendering of criteria elements inside of Criteria is limited to toString() usage. The actual mapping of CriteriaDefinition to Condition (the SQL DSL) happens in QueryMapper.
2. It depends on how close we want to bring MappingContext towards users. Ideally, we have an API that allows building comparators/query elements without leading users into Spring Data's Mapping infrastructure. Something like Postgres.arrayContains("first", "second") where the resulting value is used in Criteria so that users don't have to interact with methods exposed by the result object of Postgres.arrayContains(…). We have a similar arrangement in MongoDB with AggregationOperation. AggregationOperationContext handles some abstraction for mapping and I think we might end up doing something similar.

3. What is the custom operator is not performed on a single PersistentProperty?

This also crossed my mind. There could be variants where two functions compare against each other or the property is specified on the right side. So far, we have to consider this in some way. Let's however start from a simpler side first so that we can implement a first proof of concept before digging into the more complex things. It is typically easier to build something (starting from the side how things should be expressed in code) and then we can iterate on it towards a variant that handles an increasing number of usecases.