DATAJDBC-1953 Introduced Comparator 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