Named parameters can be provided by name and by index. Repository query methods bind parameters by name if a named parameter can be found.
If parameters are bound by index, then the parameter name is looked up by index (index corresponds with the order of parameter name discovery when parsing the query). and bound to the parameter.
We now exclude byte[] properties from being mapped to array types. To map data to a 1-dimensional BYTE[] Postgres type, properties can be declared as Collection<Byte> or Byte[].
DatabaseClient.BindSpec.bind(…) (execute) and DatabaseClient.GenericInsertSpec.value(…) (insert) now consistently accept SettableValue for scalar and absent values.
This change allows us to provide a Kotlin extension leveraging reified generics to provide the type of a value even if it is null to construct an appropriate SettableValue for fluent API usage.
We now support Converters on Entity-level if object materialization/dematerialization is handled by application code. We're using a custom R2DBC MappingContext to create mapping metadata for types that have custom converters registered.
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.
