DEV Community: Jelili Adesina

Implementing Soft Delete in Spring WebFlux with R2DBC

Jelili Adesina — Tue, 12 Nov 2024 21:12:42 +0000

Data management is a fundamental component in software development, especially when handling records that need removal from active use. Instead of permanently deleting records (a method known as “hard delete”), many applications use a technique called “soft delete.” The “soft delete” approach is a widely used solution that marks records as inactive without permanently removing them, enabling easy data recovery and historical tracking.

Currently, unlike Spring Data JPA and Hibernate, Spring Data R2DBC does not offer built-in annotations for automatically handling soft-delete. As a result, developers resort to the use of custom repository implementations or queries to achieve similar functionality.

In this article, we’ll examine soft delete, its benefits, and how to implement it in a Spring WebFlux application with R2DBC.

What is Soft Delete

Soft delete is a data management method where records are flagged as inactive or “deleted” without being removed from the database. Typically, this involves adding a field to the entity, like deleted (a boolean) or deletedDate (a timestamp), to indicate that a record is no longer active. Instead of permanently deleting data, a soft delete marks the record as logically deleted, hiding it from standard queries while preserving it for potential recovery or auditing.

Benefits of Soft Delete

Data Recovery: Soft delete allows for easy restoration of data. If a record is accidentally deleted, it can be quickly “undeleted” by resetting the flag, ensuring that no data is permanently lost.
Historical Data: Soft delete provides an audit trail. Organisations often need to keep historical data for compliance or reporting purposes, and soft delete enables this without crowding active data.
Data Integrity: In systems with complex relationships, permanently deleting a record can cause broken links and data inconsistencies. Soft delete addresses this by keeping related data intact while marking the deleted records as inactive.
Security and Compliance: Regulations often require data to be retained for specific periods. Soft delete enables developers to meet these compliance needs without making the data available to regular users.

How to implement Soft Delete with Spring Reactive and R2DBC

If you’re interested in implementing this yourself, I’ve prepared a starter code — a simple blog application with basic CRUD endpoints and unit test cases. You can access the starter code from my GitHub repository using this link. So, let's get right to it.

Step 1: Add a Field to Mark Records as Deleted

To implement this, add a field in your entity class to represent the deletion status. A more effective approach is to create an abstract class (AbstractSoftDeletableEntity), define the deletion status field within it, and have your entity class extend this abstract class. This field could either be a boolean (deleted) indicating whether the record is deleted or a timestamp (deletedDate) to specify when it was deleted. I recommend using a timestamp, as it provides the added detail of when the deletion took place:

Step 2: Modify the entity class to extend the abstract class

Modifying the entity class to extend the AbstractSoftDeletableEntity creates a level of abstraction and separation of concern, thus adhering to the Single Responsibility Principle of object-oriented design.

Step 3: Create a Generic Custom Repository Extending the SimpleR2dbcRepository

Many resources on implementing soft delete recommend using a custom repository for each entity, which can be cumbersome and hard to manage when an application has numerous entities. A better approach is to use a generic repository interface while providing custom implementations for the basic methods such as counts, deleteById, deleteAll, findById, and others.

In the snippet above, I have the SoftDeleteRepositoryImpl implementing the SoftDeleteRepository interface, which provides another abstraction layer by listing abstract methods enhanced for soft delete operation.

Step 4: Modifying the Entity Repository to extend the Custom Repository Interface

Finally, modify the main repository interface by extending the SoftDeleteRepository and providing the entity class name and the id data type as the generic type arguments. It also provides a default implementation for the findById, findAll, deleteById, and deleteAll methods to make use of the soft delete custom implementations defined in the SoftDeleteRepository interface.

Step 5: Implement Soft Delete in the Service Layer

Once you’ve completed the steps above, you’re all set. No further implementation is needed at the domain service layer. Notably, both the controller and unit test cases also required no modifications.

To fetch all records (including deleted records) or deleted records, you can make use of query methods as shown in the snippet below:

Conclusion

Soft delete is an effective and flexible method for managing data without permanently deleting it, making it ideal for applications needing data recovery, compliance, or historical data tracking. In this guide, we discussed what soft delete is, its benefits, and how it can be implemented in a Spring WebFlux application with R2DBC.

You can find the complete source code on GitHub

Internationalisation in Java

Jelili Adesina — Tue, 30 Jul 2024 21:50:15 +0000

Internationalisation (i18n) refers to designing and preparing software to be easily adapted to various languages, regions, and cultures without requiring engineering changes to the code. This is usually followed by localisation (l10n), which involves adapting the internationalised software to a specific locale, including translating the text, adjusting for local conventions, and modifying other locale-specific elements.

The goal is to make the software flexible enough to support multiple locales by separating the core logic from locale-specific elements like language and cultural conventions.

ResourceBundle

Localising a text message in a plain Java program is a bit straightforward using the ResourceBundle class provided by the programming language. The ResourceBundle class makes it easy to load, locale-specific, key-value attributes defined in properties files. These property files are known as resource bundles.

ResourceBundle resources = 
        ResourceBundle.getBundle("messages", Locale.FRANCE);
String greeting = resources.getString("greeting.hello");
assertEquals("Bonjour le monde", greeting);

String greetingUsername =       MessageFormat.format(resources.getString("greeting.username"), "Ayo");
assertEquals("Bonjour Ayo", greetingUsername);

Using i8n-resource-bundle

Another method of localising a text message in Java program is using third-party libraries. One of such library is i18n-resource-bundle. This library is an implementation over the ResourceBundle discussed earlier.

Dependency

Add the dependency below in your pom.xml if you are using Maven

<dependency>
    <groupId>io.github.jelilio</groupId>
    <artifactId>i18n-resource-bundle</artifactId>
    <version>0.0.2</version>
</dependency>

If you prefer Gradle, use this instead;

implementation 'io.github.jelilio:i18n-resource-bundle:0.0.2'

MessageSource

i8n-resource-bundle provides a MessageSource interface that defines several methods for resolving messages. It has two implementations, ResourceBundleMessageSource and ReloadableResourceBundleMessageSource. Both implementations accesses the resource bundles using specified basenames similar to Java ResourceBundle. The ResourceBundleMessageSource resolve messages form resource bundles for different locales by relying on Java’s ResourceBundle implementation in combination with MessageFormat for message parsing.

ResourceBundleMessageSource messageSource = 
        new ResourceBundleMessageSource();
messageSource.setBasenames("messages");

String greeting = messageSource
        .getMessage("greeting.hello", null, Locale.FRANCE);
assertEquals("Bonjour le monde", greeting);

String greetingUsername = messageSource
        .getMessage("greeting.username", new String[]{"Ayo"}, Locale.FRANCE);
assertEquals("Bonjour Ayo", greetingUsername);

ReloadableResourceBundleMessageSource

Unlike ResourceBundleMessageSource, the ReloadableResourceBundleMessageSource uses Java’s Properties instances as its custom data structure for messages loading them using a different strategies that allow the reloading of the properties files based on timestamp changes and a specific character encoding without the need of restarting the application.

ReloadableResourceBundleMessageSource messageSource = 
        new ReloadableResourceBundleMessageSource();
messageSource.setBasenames("messages");

String greeting = messageSource
        .getMessage("greeting.hello", null, Locale.FRANCE);
assertEquals("Bonjour le monde", greeting);

String greetingUsername = messageSource
        .getMessage("greeting.username", new String[]{"Ayo"}, Locale.US);
assertEquals("Bonjour Ayo", greetingUsername);

Conclusion

In this brief guide, we learned to implement internationalisation (i18n) in Java applications using the ResourceBundle and i18n-resource-bundle. we learned how the resource bundles are resolved based on supplied locale names and saw an example in action.

DEV Community: Jelili Adesina

Implementing Soft Delete in Spring WebFlux with R2DBC

What is Soft Delete

Benefits of Soft Delete

How to implement Soft Delete with Spring Reactive and R2DBC

Step 1: Add a Field to Mark Records as Deleted

Step 2: Modify the entity class to extend the abstract class

Step 3: Create a Generic Custom Repository Extending the SimpleR2dbcRepository

Step 4: Modifying the Entity Repository to extend the Custom Repository Interface

Step 5: Implement Soft Delete in the Service Layer

Conclusion

Internationalisation in Java

ResourceBundle

Using i8n-resource-bundle

Dependency

MessageSource

ReloadableResourceBundleMessageSource

Conclusion

References