We now allow multiple usages of the same named parameter if the underlying database supports identifiable placeholders.
SELECT * FROM person where name = :id or lastname = :id
gets translated to
SELECT * FROM person where name = $1 or lastname = $1
RowsFetchSpec.awaitOne() and RowsFetchSpec.awaitFirst() now throw EmptyResultDataAccessException instead of NoSuchElementException to consistently use Spring DAO exceptions.
We now register R2dbcRepositoryFactory as repository factory to aid Spring Data's multi-store detection so Spring Data enters strict config mode when multiple modules are on the class path.
Named parameter resolution is now provided as part of ReactiveDataAccessStrategy. This allows us to hide implementation internals (bind markers). DatabaseClient allows configuration whether to use named parameter expansion.
Detailed configuration of named parameter support is now moved to DefaultReactiveDataAccessStrategy.
Original pull request: #105.
We now provide an abstract base class for ConnectionFactory routing. Routing keys are typically obtained from a subscriber context. AbstractRoutingConnectionFactory is backed by either a map of string identifiers or connection factories. When using string identifiers, these can map agains e.g. Spring bean names that can be resolved using BeanFactoryConnectionFactoryLookup.
class MyRoutingConnectionFactory extends AbstractRoutingConnectionFactory {
@Override
protected Mono<Object> determineCurrentLookupKey() {
return Mono.subscriberContext().filter(it -> it.hasKey(ROUTING_KEY)).map(it -> it.get(ROUTING_KEY));
}
}
@Bean
public void routingConnectionFactory() {
MyRoutingConnectionFactory router = new MyRoutingConnectionFactory();
Map<String, ConnectionFactory> factories = new HashMap<>();
ConnectionFactory myDefault = …;
ConnectionFactory primary = …;
ConnectionFactory secondary = …;
factories.put("primary", primary);
factories.put("secondary", secondary);
router.setTargetConnectionFactories(factories);
router.setDefaultTargetConnectionFactory(myDefault);
return router;
}
Original pull request: #132.
We now use Spring's spring.factories mechanism to register and lookup R2dbcDialectProvider implementations.
This allows a pluggable model for third party implementations to ship R2dbcDialect support that can be auto-discovered.
Original pull request: #127.
We now reuse the existing Dialect infrastructure provided by Spring Data Relational to enhance it for R2DBC specifics such as bind markers.
Original pull request: #125.
We compressed client.execute().sql(…) to client.execute(…) to not require the intermediate execute() step but rather accept the SQL to execute directly.
Original pull request: #112.
