# Migrating from Developing Asynchronous Multi-Threading Programs to Reactive Programs in Java
## 6 Implementation Details
### Database Interactions
List<ReplyEntity> findByTweetIdOrderByCreatedAtDesc(UUID tweetId);  
@EntityGraph(attributePaths = {\"mentions\", 'hashtags\")} List<TweetEntity> findByUserIdInOrderByCreatedAtDesc(  List<UUID> userIds );  
@Query(  value = \"SELECT * FROM users WHERE user_name ILIXE '%:query%''',  nativeQuery = true )  List<UserEntity> searchUsers(String query);  
@Query(  \"SELECT NEW ro.tweebyte.interactionservice.model.ReplyDto\" +  \"(r.id, r.userId, r.content, r.createdAt, CAST(COALESCE(COUNT(), 0) AS long))  \" \" \" \" FROM ReplyEntity r \" +  \"LEFT JOIN LikeEntity 1 ON r.id = l.likeableId AND l.likeableType = 'REPLY' \"  \" \"HERE r.tweetId = :tweetId \" +  \"GROUP BY r.id, r.userId, r.content, r.createdAt \" +  \"ORDER BY COUNT(l) DESC, r.createdAt DESC\"  )  Page<ReplyDto> findTopReplyByLikesForTweetId(@Param(\"tweetId\")UUID tweetId,  Pageable pageable);  
Reactive applications can only reach their performance potential in a fully integrated and reactive ecosystem, where database access is one of the most common scenarios across current systems. Due to these constraints, adopting a reactive database access solution is a mandatory requirement. Otherwise, there is the risk of completely inheriting the complexity and overhead associated with the migration process, without being able to benefit from any of the advantages and performance improvements at a high potential level. R2 DBC is the specification selected for defining a fully responsive system and managing database interactions in a non-blocking way. The first limitation is the lack of functionality for initializing the database schema using annotations. The alternative is to explicitly define native SQL code and store it in a file within the application resources, hence setting up automatic execution at the application startup. The entities defined with R2 DBC are significantly stripped down, providing only minimal functionality for specifying the properties and metadata required for mapping these objects to the corresponding database tables. This might reduce some overhead and complexity, but it would also require a programmatic approach to achieve some functionalities comparable to ORMs. Consequently, any potential benefits could be mitigated, possibly making the system even more complex and inefficient. Recent implementations of R2 DBC provide support for version control and transactional mechanisms, but currently, there is no native support for entities using composite primary keys. This limitation required the definition of an additional unique identifier and the creation of a composite index for the fields in question, intending to preserve the equivalence following the migration process. The implementation of data access and execution of CRUD operations is performed using the _ReactiveCrdRepository_, which is the element that allows non-blocking interaction based on reactive types, ensuring seamless flow and access to data in an efficient and optimized way. R2 DBC offers a subset of predefined queries and supports custom query definitions via method naming conventions. However, it lacks several advanced features that JPA provides, such as support for JPQL (Java Persistence Query Language), which facilitates complex, object-oriented queries. Additionally, R2 DBC does not offer built-in support for caching, lazy loading, or managing relationships between entities, requiring considerable adjustments to the source code to simulate and achieve functional equivalence through programmatic management, which can be time-consuming and error-prone for bigger projects, as illustrated in Listing 3.