Introduce PreparedOperation #82
Conversation
We now consider BigDecimal and BigInteger as simple types and no longer as entities. We also no longer set properties whose value is null.
We now encapsulate prepared operations from the StatementFactory within PreparedOperation that renders SQL and provides binding values. StatementFactory supports SELECT/INSERT/UPDATE/DELETE statement creation considering Dialect-specific rendering. StatementFactory replaces String-based statement methods in ReactiveDataAccessStrategy. PreparedOperation<Update> operation = accessStrategy.getStatements().update(entity.getTableName(), binder -> { binder.bind("name", "updated value"); binder.filterBy("id", SettableValue.from(42)); }); databaseClient.execute().sql(operation).then(); Switch license header URLs to HTTPS. Rebase onto master.
mp911de force-pushed the issue/73-prepared-operation branch from 4f72724 to 8dce8ad Compare 
There was a problem hiding this comment.
The relationship between (Prepared)Operation and Statement and their respective relationship to SQL Strings confuses me and I think we should improve and clarify that.
A PreparedOperation encapsulates/creates a SQL String.
But its bind method gets a Statement as an argument which also encapsulates a SQL String.
Sometimes it seems you are suffering from the same confusion, since the StatementFactory doesn't produces Statement instances but PreparedOperation instances.
I'm wondering if we could/should implement the whole thing in a way that references to a Statement appear only in the inside of an Operation.
| /** | ||
| * Binder to specify parameter bindings by name. Bindings match to equals comparisons. | ||
| */ | ||
| interface StatementBinderBuilder { |
There was a problem hiding this comment.
I'm not a fan of that name. I made me look for a build method returning a StatementBinder and didn't help me otherwise.
How about a SomethingCustomizer or CustomizableSomething. Something might actually be Query, Statement or Operation. Again a point in the case that we need to clarify these terms.
| Yeah, let's discuss the underlying concept first and then find good names for our classes. |
| With these changes the |
| } | ||
| | ||
| @Override | ||
| public Statement bind(Connection connection) { |
There was a problem hiding this comment.
bind(…) is somewhat misleading now. That would be rather createBoundStatement(). There is now no hook that would allow us to modify the SQL that is used to create the Statement.
Right now, without #46, all this makes little sense.
Query Pre-processing would look like:
QueryFilterFunction filter = ofPreparedOperation(preparedOperation -> { PreparedOperation operation = PreparedOperation.from(preparedOperation) .filterQuery(sql -> sql + " AND tenantId = :tenant") .withBinding("tenantId", "foobar") .build(); return operation; }); filter.and(ofPreparedOperation(operation -> { AUDIT_LOGGER.info("Executed Query: " + operation.toQuery()); return operation; }))
schauder force-pushed the issue/73-prepared-operation branch from 6d0bc57 to 2265c7f Compare We now encapsulate prepared operations from the StatementFactory within PreparedOperation that renders SQL and provides binding values. StatementFactory supports SELECT/INSERT/UPDATE/DELETE statement creation considering Dialect-specific rendering. StatementFactory replaces String-based statement methods in ReactiveDataAccessStrategy. PreparedOperation<Update> operation = accessStrategy.getStatements().update(entity.getTableName(), binder -> { binder.bind("name", "updated value"); binder.filterBy("id", SettableValue.from(42)); }); databaseClient.execute().sql(operation).then(); Original pull request: #82. We now apply bindings to a BindTarget that can be overridden without the need to implement all Statement methods. PreparedOperation no longer has a direct dependency on R2DBC Statement. Original pull request: #82.
2 participants
We now encapsulate prepared operations from the
StatementFactorywithinPreparedOperationthat renders SQL and provides binding values.StatementFactory supports SELECT/INSERT/UPDATE/DELETE statement creation considering Dialect-specific rendering.
StatementFactoryreplaces String-based statement methods inReactiveDataAccessStrategy.Related ticket: #73.