delete signal listeners should use on_commit
See original GitHub issueThe delete signal handlers like https://github.com/wagtail/wagtail/blob/master/wagtail/wagtailimages/signal_handlers.py#L9 should use transaction.on_commit()
so that they wait to delete until the sql delete is successful
Something like:
from django.db import transaction
def post_delete_file_cleanup(instance, **kwargs):
transaction.on_commit(lambda: instance.file.delete(False))
Issue Analytics
- State:
- Created 6 years ago
- Comments:5 (5 by maintainers)
Top Results From Across the Web
ORM Events - SQLAlchemy 1.4 Documentation
Support for listener functions which accept the previous argument signature(s) listed above as “deprecated” will be removed in a future release. This is...
Read more >How to get notified for any change in SwiftUI TextField?
I have a UI that needs to be updated as the user makes changes in a SwiftUI TextField. How do I get notified...
Read more >SwiftUI: stay on same TextField after on commit?
iOS 15+. You can use @FocusState and, on commit, immediately set the TextField to have focus again. Example:
Read more >Spring events and transactions — be cautious! - Pragmatists
To demonstrate the problem with commit in listener, please remove @Ignore on registeredUserHasTokenGenerated method in UserResourceTest. The ...
Read more >Transaction commit, rollback listeners · Issue #2816 - GitHub
Solution 1. Manually call a handler after each save update delete call. This is mixing concerns a bit but could be made generic....
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
@BertrandBordage Sure. I will try to get to it tomorrow. I’ve already written tests that I should be able to copy and paste
This test is failing because the test uses a file name that clashes with other tests that do not clean up their test documents.
The other failing tests occur on databases other than sqllite are slightly more difficult to fix because the vagrant-wagtail-development doesn’t seem to offer testing on the different databases and travis tests are slow. Seems to be related to
serialized_rollback = True
which wasn’t required when I originally wrote the tests against postgres. But copying them over to the vagrant-wagtail-develop box seems to force sqlite