Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for Criteria composition #289

Closed
FlatMapIO opened this issue Jan 26, 2020 · 2 comments
Closed

Add support for Criteria composition #289

FlatMapIO opened this issue Jan 26, 2020 · 2 comments
Labels
type: enhancement A general enhancement

Comments

@FlatMapIO
Copy link

FlatMapIO commented Jan 26, 2020

Criteria.where(Condition) will support the construction of dynamic where clauses.

val noCondition = Conditions.just("1 = 1")
val condition = noCondition.and("name = :name").or(...)
client.select()
            .from("table")
            .matching(Criteria.where(condition))
            .fetch()
@FlatMapIO FlatMapIO changed the title Criteria support initial condition. Criteria.where() support initial condition. Jan 26, 2020
@mp911de mp911de added for: team-attention An issue we need to discuss as a team to make progress status: pending-design-work Needs design work before any code can be developed labels Jan 27, 2020
@mp911de
Copy link
Member

mp911de commented Jan 27, 2020

Thanks for the ticket. These are actually two different requirements here. First, Criteria.where(…). The second one deals with the fact of introducing the SQL DSL API into the criteria API.

Spring Data R2DBC uses the SQL DSL on a lower abstraction level to create statements by considering dialect-specifics. The example name = :name does not work here. Named parameters are resolved only for plain queries via the execute(…) API. Furthermore,

client.select()
            .from("table")
            .matching(Criteria.where(condition))
            .fetch()

does not accept parameter bindings as we expect parameters to be passed in through the Criteria object. So there's no way how we could bind the parameter.

The Criteria API was built to help with simple use-cases. It makes sense to introduce an empty Criteria object via Criteria.empty() that allows composition without the code to consider whether you're constructing the first or a subsequent Criteria segment.

@mp911de mp911de added this to the 1.1 M4 (Neumann) milestone Feb 18, 2020
@mp911de mp911de changed the title Criteria.where() support initial condition. Add support for Criteria composition Feb 18, 2020
mp911de added a commit that referenced this issue Feb 18, 2020
mp911de added a commit that referenced this issue Feb 18, 2020
We now support composition of Criteria objects to create a Criteria from one or more top-level criteria and to compose nested AND/OR Criteria objects:

Criteria.where("name").is("Foo")).and(Criteria.where("name").is("Bar").or("age")
				.lessThan(49).or(Criteria.where("name").not("Bar").and("age").greaterThan(49))
@mp911de mp911de linked a pull request Feb 18, 2020 that will close this issue
@mp911de mp911de added type: enhancement A general enhancement and removed for: team-attention An issue we need to discuss as a team to make progress status: pending-design-work Needs design work before any code can be developed labels Feb 18, 2020
mp911de added a commit that referenced this issue Mar 9, 2020
We now support composition of Criteria objects to create a Criteria from one or more top-level criteria and to compose nested AND/OR Criteria objects:

Criteria.where("name").is("Foo")).and(Criteria.where("name").is("Bar").or("age")
				.lessThan(49).or(Criteria.where("name").not("Bar").and("age").greaterThan(49))
schauder pushed a commit that referenced this issue Mar 10, 2020
We now support composition of Criteria objects to create a Criteria from one or more top-level criteria and to compose nested AND/OR Criteria objects:

Criteria.where("name").is("Foo")).and(Criteria.where("name").is("Bar").or("age")
				.lessThan(49).or(Criteria.where("name").not("Bar").and("age").greaterThan(49))

Original pull request: #307.
schauder added a commit that referenced this issue Mar 10, 2020
Refactored DefaultDatabaseClientUnitTests in order to make the relevant differences in setup easier to spot.
Formatting and nullability annotations.

Original pull request: #307.
@schauder
Copy link
Contributor

Done.

schauder added a commit that referenced this issue Mar 17, 2020
Minor formatting.

Original pull request: #308.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type: enhancement A general enhancement
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants