-
Notifications
You must be signed in to change notification settings - Fork 122
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Safe delete does not work as expected with OneToOneField #211
Comments
The django-safedelete apps does not manage OneToOneField relation so a deleted thumbnail is return in the VideoSerializer even though the thumbnail is deleted. To simply resolve this issue we check in ThumbnailSerializer.to_representation if the thumbnail is deleted and force to return False if deleted. An issue is open on the makinacorpus/django-safedelete to track this bug makinacorpus/django-safedelete#211
The relation between thumbnail and video was a OneToOneField and it is exactly the behavior we want. Unfortunately the app djang-safedelete does not manage it and it is then impossible for us to delete a thumbnail belonging to a video. The thumbnail is always return. To fix this issue we decided to change the relation with a ForeignKey field and to mimic the behavior of a OneToOneField by adding a UniqueConstraint and managing the uniqueness of the resource in the VideoSerializer. Moreover, we must keep the thumbnail instance in the VideoSerializer to avoid to query the database again and again to fetch the instance every time we need it. Without this, the number of queries is growing. An issue is open to track this bug makinacorpus/django-safedelete#211
The relation between thumbnail and video was a OneToOneField and it is exactly the behavior we want. Unfortunately the app djang-safedelete does not manage it and it is then impossible for us to delete a thumbnail belonging to a video. The thumbnail is always return. To fix this issue we decided to change the relation with a ForeignKey field and to mimic the behavior of a OneToOneField by adding a UniqueConstraint and managing the uniqueness of the resource in the VideoSerializer. Moreover, we must keep the thumbnail instance in the VideoSerializer to avoid to query the database again and again to fetch the instance every time we need it. Without this, the number of queries is growing. An issue is open to track this bug makinacorpus/django-safedelete#211
That's a complex one. The only way to currently fix that would be to overwrite the base manager on Next thing we could try is overwrite the descriptors but I think this would mean needing to have a custom I also think we have the same issue on In your test, if we want to be logic, both author and book should be deleted as the TL;DR: I'm not sure there is an easy fix for now. |
I also came across this problem and made my own solution by dynamically creating unique constraints based on the 'deleted' field in the metaclass. Inspired by this post here: https://stackoverflow.com/questions/45687127/altering-unique-fields-of-inherited-django-model. I create my own version of OneToOneField, currently called CustomOneToOneField, so I will be able to check if a given field is an instance of CustomOneToOneField and then add the appropriate unique constraints against the 'deleted' field (should probably by DELETED_BY_CASCADE_FIELD_NAME but I'm not using that and don't indent do so 'deleted' will work for now). I also had to slightly change the related_accessor_class and forward_related_accessor_class to work with actually many objects with the related key (but only one not set as deleted). There are probably some things I may be missing but I haven't ran into anything yet. The one caveat is that undeleting will break, but I am ok with that and currently do not undelete anywhere in my app. One solution would to just delete the current object and then undelete the the object you wish to undelete. Might be cool to have a field like this in this built into library at some point. here is my code:
|
On a model, if we use a
OneToOneField
relation, we expect to not access to the related model record once deleted. But in fact we can still continue to access it.I wrote test to prove it and understand what is expected on this commit : lunika@0ca7359
Thanks for your help
The text was updated successfully, but these errors were encountered: