Why doesn't R2DBC support features like lazy loading, cascading operations, or dirty checking, which are available in JPA?

[Ali Mohammad Zamani]

I'm working with Spring Data R2DBC in a reactive application and noticed that it doesn't support features like lazy loading, cascading operations, or dirty checking, which are commonly found in JPA when working with relational databases.

I understand that R2DBC is built for non-blocking, asynchronous I/O, whereas JPA typically uses blocking operations. However, I’m curious about the architectural or design decisions that might be behind the absence of these features in R2DBC.

For example, I tried to simulate cascading save with Spring WebFlux using the following pattern:

public Mono<ParentEntity> saveParentWithChildren(ParentEntity parent) {

    return saveParentEntity(parent)
        .flatMap(savedParent -> {

            // Save child entities asynchronously
            Flux<ChildEntity> savedChildren = Flux.fromIterable(savedParent.getChildren())
                    .flatMap(this::saveChildEntity); // Non-blocking child save
                   
            return savedChildren.collectList()
                    .map(children -> {
                        savedParent.setChildren(children); // Set saved children
                        return savedParent;
                    });
        });
}

However, lazy loading and cascading operations are traditionally handled by JPA in a synchronous manner, and I am wondering why these capabilities are not implemented in R2DBC.

• Is it because lazy loading and cascading operations depend on the synchronous nature of traditional ORM frameworks like JPA, while R2DBC focuses on non-blocking operations?

• Could R2DBC theoretically implement these features with the proper design adjustments, or are they fundamentally incompatible with its non-blocking architecture?

• What are the technical challenges or trade-offs when attempting to integrate these features into R2DBC?