SafeDeleteMixin is not a mixin
See original GitHub issueThe name SafeDeleteMixin
seems to say that the class is a Mixin when it’s not because it inherits from django.db.models
. Wouldn’t SafeDeleteModel
be a better name in this case? It clears up some confusion regarding inheritance.
Issue Analytics
- State:
- Created 7 years ago
- Comments:6 (3 by maintainers)
Top Results From Across the Web
Model — django-safedelete 0.4 documentation - Read the Docs
Args: keep_deleted: Do not undelete the model if soft-deleted. (default: {False}) kwargs: Passed ... SafeDeleteModel was previously named SafeDeleteMixin .
Read more >mixin and @include - Sass
A mixin's name can be any Sass identifier, and it can contain any ... the mixin as a map from argument names (not...
Read more >SASS - Why is this mixin not being included? - Stack Overflow
It is being included but you're just not calling it. % is a placeholder selector so you need to @extend %my-placeholder after you...
Read more >Using JavaScript Mixins The Good Parts - DEV Community
When NOT to use a Mixin. You may think now "dam that is powerful" and you are right. Should we use it now...
Read more >Documentation - Mixins - TypeScript
Using the mixin pattern with TypeScript. ... Mixins may not declare private/protected properties. // however, you can use ES2020 private fields. _scale =...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
I believe the previous way to use the mixin was like this:
I just got updated by unpinned dependencies and hit an issue where
safedelete_mixin_factory
is no longer included atsafedelete.models.safedelete_mixin_factory
but there are no docs that indicate the correct way to migrate from this pattern@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 olddeleted
and rename thedeleted_temp
todeleted
. 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.