Agenda 📋
In this blog post, we will explore the challenges of implementing the Soft Delete feature and discuss measures to mitigate those challenges.
What is Soft Delete? 🗑️
Often in enterprise applications, we need to provide a feature for auditing and recovering accidentally deleted data. That feature is called Soft Delete.
The definition of soft delete is pretty simple: deleting data at a logical level instead of actually deleting it in the database. Implementation-wise, it's straightforward as well: marking data as deleted in the database layer and ignoring that data in the application layer.
Challenges of Implementing Soft Delete 🚧
Even though the feature seems simple to implement, maintaining it in the whole project can be a burden for developers. Let's delve into why.
1. Development Burden 😩
When implementing any logic, developers need to consider the presence of soft deleted data. Business logic must filter out soft deleted data to ensure the application returns valid data. Without a clear abstraction this may lead to system failure.
2. Unique Data Constraint with Soft Delete 🔄
Implementing validation constraints at the database layer is crucial for data integrity. However, uniqueness validation constraints don't align well with the soft delete feature.
As we're not actually deleting the data in the database, but rather marking it as deleted, a uniqueness constraint can lead to confusion. Subsequent attempts to save the same data may result in a duplicate key error, without clear indication as to why.
Solutions to Mitigate Challenges 🛠️
1. Development Burden
Frameworks often promote the 3-tier architecture for software development. By leveraging this architecture, we can easily ignore soft deleted data at the data tier (e.g., Data Access Layer/Repository Layer). This ensures that data returned by the layer is filtered to exclude marked deleted data, allowing the service layer to process only relevant data.
For instance, in Spring Boot, JPA is commonly used for database access. By creating a custom SoftDeleteRepository that filters out soft deleted data, we can ensure that repository layer classes consistently return data without soft deleted entries.
2. Unique Data Constraint with Soft Delete
Dealing with unique constraints at the database level can be tricky. One way to mitigate this issue is by using Partial Indexing. Many modern databases support this feature, where an index is applied based on defined conditions.
For example, if we have a boolean marker property named deleted, with true indicating a deleted entry and false indicating an active one, we can apply a partial index to exclude deleted entries. This ensures that unique constraints only apply to active data, preventing conflicts with soft deleted entries.
Conclusion 🎉
In this post, we've explored the challenges of the soft delete pattern and discussed techniques to mitigate them at both the application and database levels.
Demo Project Link 🔗
Check out a demo project showcasing the soft delete feature using Spring Boot and MongoDB: Spring Boot MongoDB Soft Delete
Top comments (0)