SafeDeleteMixin is not a mixin

[AndreasBackx]

The name SafeDeleteMixin seems to say that the class is a Mixin when it's not because it inherits from django.db.models. Wouldn't SafeDeleteModelbe a better name in this case? It clears up some confusion regarding inheritance.

[Gagaro]

I agree. SafeDeleteMixin should be deprecated in the 0.4.x (it's not released yet but I'm not sure it is not used yet).

[thenewguy]

I believe the previous way to use the mixin was like this:

from safedelete.models import safedelete_mixin_factory, SOFT_DELETE
SoftDeleteMixin = safedelete_mixin_factory(SOFT_DELETE)

I just got updated by unpinned dependencies and hit an issue where safedelete_mixin_factory is no longer included at safedelete.models.safedelete_mixin_factory but there are no docs that indicate the correct way to migrate from this pattern

[Iftahh]

@thenewguy did you find a solution? I hit the same issue.

I got the Mixin replacement:

  class SafeDeleteMixin(safedelete.models.SafeDeleteMixin):
    _safedelete_policy = SOFT_DELETE   # replace by whatever you want
    _safedelete_visibility = DELETED_VISIBLE_BY_FIELD  # replace by whatever you want
    
    class Meta:
        abstract = True

but the next problem I faced is making the database migration - the deleted field changed from BooleanField to DateTimeField which cannot be automatically populated.

[AndreasBackx]

@thenewguy the example is pretty clear on how to use the new "Mixin". Inherit from SafeDeleteMixin.

@Iftahh It should be easy to populate from BooleanField to DateTimeField. If true, set the DateTimeField to the current time, else set it to None. There should've been something in the docs about moving from 0.3.x to 0.4.x in my opinion. Could we perhaps add this in the README @Gagaro?

[Gagaro]

Yes indeed I completely forgot about documenting the migration. Sorry about that.

I'm really busy these days, I'll do that ASAP but I don't know when it will be. You can pin on 3.5 in the meantime.

[Iftahh]

@AndreasBackx yes, the logic is simple but still its not as easy as "normal" Django migrations - you have to add a column of type datetime (eg. deleted_temp) populate it, remove the old deleted and rename the deleted_temp to deleted.
Still after that was done I had different unit tests failures that I decided to just revert the database and freeze version to 0.3.2.