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.