<h4>Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.</h4>
<figure><img alt="" src="https://cdn-images-1.medium.com/max/1024/0*0jvWLbXENhbH5Q2b"><figcaption>Photo by <a href="https://unsplash.com/fr/@markuswinkler?utm_source=medium&amp;utm_medium=referral">Markus Winkler</a> on <a href="https://unsplash.com/?utm_source=medium&amp;utm_medium=referral">Unsplash</a></figcaption></figure>Originally published on my <a href="https://tomisin.dev/blog">blog</a>.
In contemporary architecture, or by design requirements, we often have the need to keep certain records even after they’ve been “deleted” by the user — that’s where soft deletion comes in.
In this article, we would learn how to implement soft delete, while our application maintains its Django-ness (for lack of a better word), and we can still maintain the same interface with our model objects in the same way as we would, if we had hard deletion in place.
<h3>What is Soft Delete</h3>
Soft delete is the process of deleting records in such a way that it is still present in the database while made unavailable to the user. It involves using a flag to mark the record as unavailable, rather than deleting the record from the database.
<h3>Benefits of Soft Delete</h3>
<ol>
<li>Records are easier to restore.</li>
<li>Soft delete operations are faster because we run an UPDATE command in the database. For hard delete, we will run a DELETE command which is generally slower, especially when there are related records across tables.</li>
<li>It keeps are related records in-place.</li>
<li>It is the safer option, in cases where users may need to retrieve deleted information.</li>
</ol>
<h3>Cons of Soft Delete</h3>
<ol>
<li>Added complexity of filtering out records that have been flagged as deleted.</li>
<li>Unique constraints need to be refactored to include the column representing the delete flag, so records which have been soft deleted could be recreated.</li>
<li>In some cases, records might need some unique implementations when soft deleted. For example, when soft deleting card information or payment methods, we might need to clear some sensitive fields like PAN or CVV.</li>
</ol>
Some of these fetch queries will start to look like
<pre>SELECT * FROM users WHERE is_deleted=false;</pre>
Unique constraints would also start to look this, with soft deletion in place:
<pre>CREATE UNIQUE INDEX "users_unique" ON users(is_deleted, email) WHERE is_deleted=false;</pre>
<h3>Implementing Soft Delete in Django</h3>
When implementing soft delete in Django, the first thing that’s required is a base model. This would reduce the complexity and help eliminate the aforementioned cons, as we wouldn’t need to duplicate the soft delete logic in all our models. All we would need to do, is to extend from this BaseModel.
<pre>class BaseModel(models.Model): class Meta: abstract = True # common fields go here</pre>
The first thing we want to add to our base model, is the delete flag. The is_deleted field will inform us about the availability of the record.
<pre>class BaseModel(models.Model): # ...omitted for brevity... is_deleted = models.BooleanField(default=False)</pre>
Next, we override the delete method of the model. So, we can change the default behaviour of our model’s delete from hard deletion to soft deletion.
<pre>class BaseModel(models.Model): # ...omitted for brevity... def delete(self): """Mark the record as deleted instead of deleting it""" self.is_deleted = True self.save()</pre>
With this piece of code in place, we could soft delete records as we would normally hard delete records, and maintain a Django-ic codebase.
<pre>class User(BaseModel): class Meta: unique_together = ['email', 'is_deleted'] name = models.CharField(max_length=24) email = models.EmailField() new_user = User(name="Bolaji", email="user.test@example.com") new_user.save() print(User.objects.all() # &lt;QuerySet [&lt;User: Bolaji&gt;]&gt; new_user.delete() print(new_user.is_deleted) # True print(User.objects.all()) # &lt;QuerySet []&gt;</pre>
Now that we can soft delete easily, we have to make sure that our query results never actually include any deleted record. We do so by creating a custom manager which filters out the deleted.
<pre>from django.db.models import Manager, QuerySet class AppManager(Manager): def get_queryset(self): return QuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(model.Model): # ...omitted for brevity... objects = AppManager()</pre>
With this in place, we can replace the default objects field of our Model with our AppManager. This would ensure that when we query using the familiar syntax, we are getting expected
<pre>class User(BaseModel): # ...omitted for brevity... user.objects.filter(...) user.objects.all() # queries now exclude records flagged as deleted.</pre>
Wowza! Now, you can soft delete records while maintaining Django-ic code. Or, maybe there’s one more thing…
It’s possible to invoke delete on a queryset, instead of invoking it on an object. We have already catered for the latter my having a custom delete method in our BaseModel. To cater for the former scenario, we can make a custom queryset class.
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True)</pre>
Putting this altogether, we have:
<pre>from django.db.models import Manager, QuerySet class AppQuerySet(QuerySet): def delete(self): self.update(is_deleted=True) class AppManager(Manager): def get_queryset(self): return AppQuerySet(self.model, using=self._db).exclude(is_deleted=True) class BaseModel(models.Model): class Meta: abstract = True is_deleted = models.BooleanField(default=False) def delete(self): self.is_deleted = True self.save() # Sample model class Post(BaseModel): content = models.CharField(max_length=140) def __str__(self): return self.content # Create a post post = Post(content="Hello World") post.save() # Get all posts print(Post.objects.all()) # &lt;QuerySet [&lt;Post: Hello World&gt;]&gt; # Delete the post post.delete() print(Post.objects.all()) # &lt;QuerySet []&gt;</pre>
Finally, you have soft delete implemented, and you didn’t have to change your contract. Thanks for reading, buddy!
Leave a clap, share this article and do subscribe, if you found this article helpful.
<a href="https://tomisin.dev/subscribe">Subscribe * Tomisin Abiodun</a>

Learn how Django models could implement soft delete, without modifying the interfaces and contracts of models and querysets.

Contents

database

django

python

web-development

Implementing Soft Delete in Django: An Intuitive Guide

People also read