Of course, the Spring Data team could not resist the appeal of implementing the ReactiveCrudRepository interface on top of R2DBC. At the moment of writing, this implementation lives in the Spring Data JDBC module, which has already been described in this chapter. However, it is going to obtain its own module called Spring Data R2DBC. The SimpleR2dbcRepository class implements the ReactiveCrudRepository interface using R2DBC. It is worth noting that the SimpleR2dbcRepository class does not use the default R2DBC Client but defines its own client to work with R2DBC SPI.
Before Spring Data R2DBC kick-off, reactive support in the Spring Data JDBC module lives in the r2dbc Git branch of the project and, consequently, is not yet ready for production. However, the Spring Data JDBC module with R2DBC support demonstrates the vast potential of using ReactiveCrudRepository for relational data manipulation. So, let's define our first ReactiveCrudRepository for PostgreSQL. It may look as follows:
public interface BookRepository extends ReactiveCrudRepository<Book, Integer> { @Query("SELECT * FROM book WHERE publishing_year = " + "(SELECT MAX(publishing_year) FROM book)") Flux<Book> findTheLatestBooks(); }
So far, the Spring Data JDBC module does not have auto-configuration, so we have to create an instance of the BookRepository interface manually:
BookRepository createRepository(PostgresqlConnectionFactory fct) { // (1) TransactionalDatabaseClient txClient = // (2) TransactionalDatabaseClient.create(fct); RelationalMappingContext cnt = new RelationalMappingContext(); // (3) return new R2dbcRepositoryFactory(txClient, cnt) // (4) .getRepository(BookRepository.class); // (5) }
In the preceding code, we do the following steps:
- We need a reference to PostgresqlConnectionFactory, which was created in the previous example.
- TransactionalDatabaseClient enables basic support for transactions.
- We have to create a simple RelationalMappingContext in order to map rows to entities and vice versa.
- We create an appropriate repository factory. The R2dbcRepositoryFactory class knows how to create ReactiveCrudRepository.
- The factory generates the instance of the BookRepository interface.
Now, we may use our entirely reactive BookRepository in a normal reactive workflow, as follows:
bookRepository.findTheLatestBooks() .doOnNext(book -> log.info("Book: {}", book)) .count() .doOnSuccess(count -> log.info("DB contains {} latest books", count)) .subscribe();
Even though the R2DBC project is still experimental, as well as its support in Spring Data JDBC, we may see that genuinely reactive data access is not very far away. Besides, the problem of backpressure is resolved at the R2DBC SPI level.
At this point, it is unclear whether ADBA will receive reactive support or whether R2DBC will become a reactive alternative to ADBA. However, in both cases, there is confidence that the reactive relational data access will become a real thing very soon, at least for databases with either ADBA- or R2DBC-compliant drivers.