django-safedelete
django-safedelete copied to clipboard
makinacorpus
Adding a new Delete Policy: SOFT_DELETE_INHERIT
In some case, let's say you want to soft delete a model, and use the own related models policy to know what to do with these related objects.
For example, with the following code:
class Person(SafeDeleteModel):
_safedelete_policy = SOFT_DELETE_INHERIT
name = models.CharField(max_length=128)
class Group(SafeDeleteModel):
_safedelete_policy = SOFT_DELETE_INHERIT
name = models.CharField(max_length=128)
members = SafeDeleteManyToManyField(Person, through='Membership')
class Membership(SafeDeleteModel):
_safedelete_policy = HARD_DELETE
person = models.ForeignKey(Person, on_delete=models.CASCADE)
group = models.ForeignKey(Group, on_delete=models.CASCADE)
invite_reason = models.CharField(max_length=64)
In that case, when you soft delete a Person, the membership is really deleted from the DB. By the way, this could be one workaround to problem described in this issue.
More generally, this policy give the power back to the class itself, to determine what to do, and is more flexible that SOFT_DELETE_CASCADE.
It can behave exactly like SOFT_DELETE_CASCADE if Person is SOFT_DELETE_INHERIT and Membership is SOFT_DELETE
What do you think of this? Can you see any design flaw or potential problem with this? For now, I tried implementing it locally and it seems to do the job.
If that sounds interesting to you, I will propose a PR.
I think we're starting to have too many policies, and this is getting confusing. We should probably refactor that a bit.
I think we can separate the delete settings from the cascade one. We could have something like:
class Person(SafeDeleteModel):
_safedelete_delete_policy = SOFT_DELETE
_safedelete_cascade_policy = INHERIT
name = models.CharField(max_length=128)
With SOFT_DELETE, HARD_DELETE and NO_DELETE, INHERIT for the delete policy, and NO_CASCADE and CASCADE for the cascade one, we should be able to cover pretty much every case.
What do you think about that?
Yes, I really like the idea of splitting both policies, it is a lot clearer and more flexible as well!
@Gagaro I'm not kidding you when I say that I was actually gonna post the same idea, but scrapped it cause I was so hungry I'd think of it after I had lunch. I also had the exact same variable and constant names. For a second I thought that I had actually posted it and that was my comment.
