spring-data-r2dbc | Provide support to increase developer productivity | Reactive Programming library

I got an answer from 'Mark Paluch' below; this worked for me. So now I'm able to connect to Redshift using Postgres drivers.

Amazon Redshift is based on Postgres, so you should use the Postgres driver. This mailing list handles R2DBC specification aspects only. If you're looking for support for a specific library built on top of R2DBC, please reach out to the actual maintainers through their, e.g., GitHub project.

Pom.xml

When I switch to map instead of flatMap then it does not work

map operator is designed to perform 1 to 1 synchronous operations like a simple object mapping. On the other hand, flatMap is used for asynchronous I/O operations like as in your case. See map vs flatMap in Reactor

When i want to do another operation after the saving to database

You could use a second flatmap like this:

r2dbc does not support page/slice type, so you can do this:

R2DBC is primarily a specification to enable reactive/non-blocking communication with your database. What an R2DBC driver is capable of pretty much depends on your database.

R2DBC specifies a set of interfaces including methods where every database conversation is activated through a Publisher. R2DBC has no opinion on the underlying wire protocol. Instead, a database driver implementing R2DBC has to stick to its database communication protocol. What you get through JDBC or ODBC is pretty much the same as what you can expect from an R2DBC driver.

There are smaller differences: some JDBC drivers require polling for data (such as Postgres Pub/Sub notification) whereas, in R2DBC, a notification stream can be consumed without a polling thread as all I/O is based on listening on the receive buffers and emitting data once the driver receives data. In contrast, JDBC (and pretty much all imperative API) require someone to call a method to consume/obtain data.

I'm not sure how CDC works with MySQL; I think you need to scan (poll) the BINLOG using MySQL commands or the MySQL protocol. Right now, the R2DBC MySQL driver doesn't support BINLOG polling.

Postgres has similar functionality (Logical Decode). It is supported by R2DBC Postgres (see the documentation of Logical Decode using R2DBC Postgres). In Postgres, the server pushes the replication log to the client, which gives you a hot stream as logical decode subscribes to the replication log.

The gist is pretty much that it depends on the actual database technology.

Alright mate, firstly, why exactly does this "Due" entity need to be its own entity? I mean, a task may have a deadline and it may be recurring. Keep it simple.

Regarding the code, irrespective of domain modelling aspects:

Use Long or UUID as ID field types. Personally, I've never seen int in production.

Create a CrudRepo for those "Due" entities to check out whether you can query them on their own. Write a test to verify that.

My guess is that the "JoinTable" annotation is somehow redundant and/or misconfigured. Try "Due.ID" instead of "Due_ID" to tell it which field of the Due object it should take.

It's turned out that my second attempt IS the solution.

The trick was in my Run/Debug configuration for tests.

In IDEA Preferences I have checked Preferences | Build, Execution, Deployment | Build Tools | Maven | Runner — Delegate IDE build/run actions to Maven checkbox, and this means that I need to manually recompile my project before running tests.

So, this is it, the solution for error

Answering my own question.

TLDR

• Having org.springframework.boot:spring-boot-starter-data-r2dbc:2.3.5.RELEASE is enough to have connection pooling enabled by default
• No need to add io.r2dbc:r2dbc-postgresql explicitly
• No need to put :pool: in the URL in this case

Some detailed findings. it seems there are two ways to enable connection pool:

1. Put :pool: driver chunk into the URL and then io.r2dbc.pool.PoolingConnectionFactoryProvider#create will take care of creating a Connection Pool. This is described at https://github.com/r2dbc/r2dbc-pool#getting-started
2. Do not have spring.r2dbc.pool.enabled=false in configs (meaning that its absence is interpreted as true by default). This way a Connection Pool will be created by the org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryConfigurations.Pool#connectionFactory. I am not sure, but it looks like a generalized Spring Boot configuration-style override over a library specific :pool: option.

This options are independent and partly overlap and the second one takes precedence.

The second component evaluates also presence of the :pool: in the URL (see org.springframework.boot.autoconfigure.r2dbc.ConnectionFactoryConfigurations.PooledConnectionFactoryCondition) and if found it delegates the creation of the Connection Pool to the first one.

There is also a peculiar conclusion - having explicit spring.r2dbc.pool.enabled=false leads to creation of a Connection Pool anyway if there is a :pool: in the URL. Therefore the only way to disable pooling is to have spring.r2dbc.pool.enabled=false and to omit :pool: in the URL at the same time.

I think this is because your id is long, not Long.

Having it as long, it always has a value, and because Spring Data R2DBC has no idea about your schema and that it will be automatically generated, it includes the value in the insert statement.

If you switch it to Long, as it will be null if not set, it should not include it in the insert statement (or at worse set it to null) and the value should be generated by the database because of the default value you configured.

There's no as(Class) API after the migration to Spring R2DBC.

DatabaseClient started its journey in the experimental Spring Data R2DBC project, trying out various approaches. One of them evaluated how close a textual SQL API and an object-mapping API could be brought together. DatabaseClient in Spring Data exposed various API methods such as select().from("table").as(targetType).

It turned out that this functionality is useful but draws certain limitations because the more an API goes into an entity or even aggregate-oriented direction, the more complexity the actual API becomes and at some point, boundaries between simple object mapping and entities (for example, entity lifecycle callbacks) blur.

We decided to introduce R2dbcEntityTemplate as an abstraction for all entity-bound operations to support most common use-cases. Looking at the fluent API that was previously in place, there's still a gap for all use-cases that require ad-hoc SQL queries, aggregations, function calls, etc.

In the meantime, the project proved useful, and we've identified core support classes that could be migrated into Spring Framework 5.3, so Spring Data R2DBC 1.2 could be based on top of Spring R2DBC.

We weren't able to come up with a proper approach while migrating the code. To be fair, DatabaseClient offers almost the same level of abstraction (except for stored procedures) as NamedParameterJdbcTemplate. Spring JDBC ships clearly with several RowMapper implementations such as SingleColumnRowMapper or DataClassRowMapper that would be useful for Spring R2DBC, too.

From a user-perspective, as(…) sees a lot of demand and we should investigate, how this functionality (or a variant of it) could be surfaced.