See r2dbc/r2dbc-spi#124.

See r2dbc/r2dbc-spi#49

Currently, custom values can be stored in scope of method and query execution with these methods in MethodExecutionInfo and QueryExecutionInfo.

- void addCustomValue(String key, Object value);
- <T> T getCustomValue(String key, Class<T> type);

To add more scope(bind param, connection), create a new interface ValueStore that defines custom value handling methods.

I am experimenting the decorator/proxy to convert custom bind markers to the one that target database can understand.

I have created bind-param-converter branch and added preliminary implementation.
Based on the change, I have created a sample impl that performs parameter conversion.

tl;dr

conn.createStatement("INSERT INTO names (first_name, last_name) VALUES (:FIRST:, :LAST:) ")
    .bind(":LAST:", "FOO")
    .bind(":IGNORE:", "will be ignored")
    .bind(":FIRST:", "foo")
    .execute()

becomes

Query:["INSERT INTO names (first_name, last_name) VALUES (?, ?) "] Bindings:[(foo,FOO)]

Implementation

There are two intercepting points to consider for bind parameter substitution.

1. Connection#createStatement(sql)
   Here needs to convert the given query by replacing the custom placeholder to actual placeholder that target database can understand.
   e.g.: INSERT INTO names VALUES ( :first_name, :last_name ) => INSERT INTO names VALUES ( ?, ? )
   Additionally, construct a map that contains position information for placeholder to avoid parsing query at bind operations.
   e.g.: {"first_name":0,"last_name":1}
   Also, requires a way to pass this map to the bind operation callback.

2. bind/bindNull operations
   When performing bind operations, callback should be able to alter the actual behavior including not performing binding at all.
   e.g.: stmt.bind(":first_name", "foo") => stmt.bind(0, "foo")

In the branch commit, BindParameterConverter is the interface for the above callbacks.

In the sample implementation, NamedBindParameterConverter.java covers following usecases:

• Convert colon surrounded parameter(:name:) to ?
• Pass the parameter-index map from onCreateStatement to onBind
• Convert placeholder specific parameters to position index based bindings
• When :IGNORE: is specified in bind key, skip performing actual bind. (Demonstrating skip behavior).

Need more polishing on the changes, but this is the first step for supporting bind marker replacement story in r2dbc-proxy.

cc @nebhale @mp911de

Following methods return the invoked object itself

• Batch#add
• All methods on Statement except execute

Currently, those self returning methods are returning actual result of invocation.
They should return invoked proxy object.

Allow user to store custom values in logical connection scope.

relates to #29

r2dbc/r2dbc-spi#54
r2dbc/r2dbc-spi#94

Currently, ProxyConnectionFactory and its builder are the entry point to wrap original ConnectionFactory, register listeners, and create proxy ConnectionFactory.

When other raw r2dbc objects(Connection, Batch, Statement, Result) need to participate r2dbc-proxy framework(wrap to proxy), ProxyFactory provides methods to wrap them.

ProxyFactory is obtained from ProxyConfig and currently it does not have builder API.

We need to provide a builder for ProxyConfig and gives similar experience to ProxyConnectionFactory.Builder when constructing ProxyConfig instance.

[r2dbc/r2dbc-spi#9]

Bug Report

I found some errors running perf test using the proxy around a ConnectionPool

Versions

• Driver: 0.8.RELEASE
• Database: postgres
• Java: 1.11
• OS: ubuntu

Current Behavior

Using a proxy around a ConnectionPool do some error running perf test on my api.
We found some error like

• java.lang.IndexOutOfBoundsException: Source emitted more than one item.
• org.springframework.transaction.IllegalTransactionStateException: Transaction is already completed - do not call commit or rollback more than once per transaction
• org.springframework.transaction.TransactionSystemException: Could not commit R2DBC transaction; nested exception is io.r2dbc.postgresql.ExceptionFactory$PostgresqlNonTransientResourceException: [34000] portal "B_986" does not exist

When I remove the proxy all is OK. Using the proxy on the ConnectionFactory instead of the ConnectionPool all is OK.

Table schema

This issue is not linked with a specific table.

Steps to reproduce

Create a Java API performing a get on a transaction using Spring Boot.
The proxy configuration is done using something like that;

@Configuration
public class R2dbcConfiguration {

    private final Tracer tracer;

    public R2dbcConfiguration(Tracer tracer) {
        this.tracer = tracer;
    }

    /**
     * this is a copy/past of org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryConfiguration.ConnectionPoolConnectionFactoryConfiguration
     * waiting an r2dbc zipkin implementation provided by Spring (see https://github.com/spring-projects-experimental/spring-boot-r2dbc/issues/71)
     */
    @Bean(destroyMethod = "dispose")
    public ConnectionPool withTracing(R2dbcProperties properties,
                                  List<ConnectionFactoryOptionsBuilderCustomizer> customizers) {
        ConnectionFactory connectionFactory =  ConnectionFactoryBuilder.create(properties).customize(customizers)
            .build();
        R2dbcProperties.Pool pool = properties.getPool();
        ConnectionPoolConfiguration.Builder builder = ConnectionPoolConfiguration.builder(connectionFactory)
            .maxSize(pool.getMaxSize()).initialSize(pool.getInitialSize()).maxIdleTime(pool.getMaxIdleTime());
        if (StringUtils.hasText(pool.getValidationQuery())) {
            builder.validationQuery(pool.getValidationQuery());
        }
        return new ConnectionPool(builder.build());
    }

    @Primary
    @Bean
    public ConnectionFactory connectionFactoryWithTracing(ConnectionFactory original) {
        return ProxyConnectionFactory.builder(original)
            .listener(new TracingExecutionListener(tracer))
            .build();
    }
}

Expected behavior/code

No exception like without using the proxy.

LifeCycleListener and QueryInfo need javadoc.

#1 (comment)
#1 (comment)

Not sure if anything is required, but if so support Statement.returnGeneratedValues(String...)

r2dbc/r2dbc-spi#25

ProxyConnectionFactory.Builder API defines method/query callbacks as:

• onBeforeMethod(Consumer<Mono<MethodExecutionInfo>> consumer)
• onAfterMethod(Consumer<Mono<MethodExecutionInfo>> consumer)
• onBeforeQuery(Consumer<Mono<QueryExecutionInfo>> consumer)
• onAfterQuery(Consumer<Mono<QueryExecutionInfo>> consumer)
• onEachQueryResult(Consumer<Mono<QueryExecutionInfo>> consumer)

Usage of Mono<*Info> is not appropriate since it requires implementor to subscribe it even though the actual value has already emitted.
Instead, they should be Consumer<*Info> to directly receive contextual object as ProxyExecutionListener API defines.

A sample project to apply r2dbc-proxy framework via java agent.

• Intercept ConnectionFactory#create method
• Make it return a publisher that produces wrapped Connection
• use ProxyFactory#wrapConnection() to wrap Connection

Relates to [r2dbc/r2dbc-spi#9]

Move the README.md contents in datasource-proxy-r2dbc to the asciidoc documentation

To reduce memory usage, use Atomic*Updater for classes that get created frequently such as DefaultConnectionInfo instead of Atomic*.

Currently, when Connection#close() is performed, callback handler(ConnectionCallbackHandler)
casts the ConnectionInfo to its default implementation class DefaultConnectionInfo to update
connection closing info(setClosed(true)).

This obviously doesn't work if non default implementation of ConnectionInfo is used. (e.g.: when making Connection participate proxy framework via ProxyFactory).

Need to move setClosed() to ConnectionInfo interface, and do not rely on the implementaion class in callback handler.

When JDK dynamic proxy is used for creating a proxy, the proxy invocation(InvocationHandler#invoke()) passes a Method object that corresponding to the interface of the proxy instance.
On the other hand, ByteBuddy invocation passes Method of the actually invoked class via @Origin Method parameter.

Currently, in LifeCycleExecutionListener, first set of method dispatching compares Class of passed Method#getDeclaringClass().
For JDK dynamic proxy, this class becomes interface class(e.g.: ConnectionFactory). However, for ByteBuddy case, this class becomes actual target class(e.g.: H2ConnectionFactory).
Therefore, following dispatching mechanism doesn't work:

Class<?> methodDeclaringClass = method.getDeclaringClass();

if (ConnectionFactory.class.equals(methodDeclaringClass)) {
    // ConnectionFactory methods
    if ("create".equals(methodName)) {
      ...
    }
} else if (Connection.class.equals(methodDeclaringClass) {
   ...
} else if (...)

This if-else logic needs to be updated to work with any case regardless of impl or interface Method are passed.

From gitter discussion:
https://gitter.im/R2DBC/r2dbc?at=5e1c726865540a529a0c9366

I have reproduced the issue using H2 with ReactiveCrudRepository#save

@GetMapping("/insert")
//    @Transactional
public Mono<City> insert() {
  City city = new City("name", "country");
  return this.repository.save(city)
    .doFinally(signal -> {
      System.out.println("CONTROLLER signal=" + signal);
    });
  };

The method are called in following sequence:

[ 33] [before-method] io.r2dbc.spi.ConnectionFactory#create
[ 34] [after-method] io.r2dbc.spi.ConnectionFactory#create
[ 35] [before-method] io.r2dbc.spi.Connection#createStatement
[ 36] [after-method] io.r2dbc.spi.Connection#createStatement
[ 37] [before-method] io.r2dbc.spi.Statement#bind
[ 38] [after-method] io.r2dbc.spi.Statement#bind
[ 39] [before-method] io.r2dbc.spi.Statement#bind
[ 40] [after-method] io.r2dbc.spi.Statement#bind
[ 41] [before-method] io.r2dbc.spi.Statement#returnGeneratedValues
[ 42] [after-method] io.r2dbc.spi.Statement#returnGeneratedValues
[ 43] [before-query] Query:["INSERT INTO city (name, country) VALUES ($1, $2)"]
[ 44] [before-method] io.r2dbc.spi.Statement#execute
[ 45] [before-method] io.r2dbc.spi.Result#map
[ 46] [before-method] io.r2dbc.spi.Connection#close
[ 47] [after-method] io.r2dbc.spi.Connection#close
CONTROLLER signal=onComplete
[ 48] [after-method] io.r2dbc.spi.Result#map
[ 49] [after-method] io.r2dbc.spi.Statement#execute
[ 50] [after-query] Query:["INSERT INTO city (name, country) VALUES ($1, $2)"]

The (34), 48, 49 receives cancel signal.

According to @mp911de

save(…) calls either insert or update methods and takes the first() element of the result
See https://github.com/spring-projects/spring-data-r2dbc/blob/master/src/main/java/org/springframework/data/r2dbc/repository/support/SimpleR2dbcRepository.java#L74-L97

cc/ @aravindtga @Squiry

r2dbc/r2dbc-spi#73

See r2dbc/r2dbc-spi#118.

Hi, this is a first-timers-only issue. This means we've worked to make it more legible to folks who either haven't contributed to our codebase before or even folks who haven't contributed to open source before.

If that's you, we're interested in helping you take the first step and can answer questions and help you out as you do. Note that we're especially interested in contributions from people from groups underrepresented in free and open source software!

If you have contributed before, consider leaving this one for someone new, and looking through our general ideal-for-contribution issues. Thanks!

Background

R2DBC's ConnectionFactories is the gateway to obtain a ConnectionFactory from a ConnectionFactoryOptions object. ConnectionFactoryOptions is a configuration object that holds the connection configuration in order to obtain a ConnectionFactory from the appropriate driver.

In r2dbc-proxy, io.r2dbc.proxy.ProxyConnectionFactoryProvider is the class that receives ConnectionFactoryOptions and produce ConnectionFactory.

Problem

ConnectionFactoryOptions can be constructed by parsing a connection URL string or by programmatically.

For example with this URL:

r2dbc:proxy:postgresql://user@pass:localhost:5432/test-db?proxyListener=com.example.ListenerA,com.example.ListenerB

The parser will generate an Option object where key is proxyListener and value is String of com.example.ListenerA,com.example.ListenerB.

Current implementation of io.r2dbc.proxy.ProxyConnectionFactoryProvider is NOT supporting comma separated list of class names when it handles proxyListener parameter.

Solution

io.r2dbc.proxy.ProxyConnectionFactoryProvider should accept comma separated String value for proxyListener parameter.

When proxyListener option value is a String, treat it as a comma separated list of listener class names. Iterate over each of those listener class names. They need to be instantiated and registered as proxy listeners.

Steps to fix

• Claim this issue with a comment below and ask any clarifying questions you need.
• Set up a repository locally following the Contributing Guidelines.
• Try to fix the issue following the steps above.
• Commit your changes and start a pull request.

Deliverables

• Changed io.r2dbc.proxy.ProxyConnectionFactoryProvider
• Changed unit test io.r2dbc.proxy.ProxyConnectionFactoryProviderTest
• Changed README.md - description of connection discovery options

related PR: r2dbc/r2dbc-spi#48
related issue: r2dbc/r2dbc-spi#37

reference: r2dbc/r2dbc-spi#127

reference: r2dbc/r2dbc-spi#128

#1 (comment)

Evaluate the changes in r2dbc/r2dbc-spi#42 for updates in this implementation.

ProxyFactory implementation with:

• Byte Buddy (https://gist.github.com/ttddyy/e930ae206ef799a4ec834155294cdcf1)
• Spring AOP framework (cglib underneath)

Also, demonstrate how to configure those ProxyFactory implementations. (Relates to [#10])

Relates to [r2dbc/r2dbc-spi#9]

Proxy creation(ProxyFactory) and proxy handling logic(~CallbackHandler) are separated by design.
This is to allow different proxy mechanism can be applied and to reuse the same proxy handling logic.
Currently, ~CallbackHandler are scoped in package private and cannot be reused outside of the framework.
To facilitate different proxy mechanism to use the handler logic, these ~CallbackHandler classes need to be updated to public classes.

Currently, when proxy object is called, callback handler performs reflective invocation on actual target instance. When ByteBuddy is used to intercept method calls, this causes a problem.

For example, if ConnectionFactory#create() is instrumented, first create() call gets intercepted. Then, ConnectionFactoryCallbackHandler reflectively calls the original object to get the result. This call will again get intercepted; so, it ends up with infinite loop of interception.
To avoid this loop, ByteBuddy provides @SuperCall annotation on Callable to retrieve actual invocation result.

By making target-method-call as a strategy and replaceable, for ByteBuddy case, it can create a strategy to retrieve actual result from @SuperCall Callable parameter instead of reflectively call on target instance.

Should this project implement ConnectionFactory discovery?

r2dbc/r2dbc-spi#10