| | 19 | |
| | 20 | Update: |
| | 21 | |
| | 22 | This would fix taking too long to load the delete_selected_confirmation.html and delete_confirmation.html templates, but does NOT address the action deletion. |
| | 23 | From what I understand, deleting an object with a million references has 2 main issues: |
| | 24 | |
| | 25 | - Loading the confirmation templates (which we address here) |
| | 26 | - The actual deletion database operation, which happens after the confirmation |
| | 27 | |
| | 28 | The actual deletion operation from the database can also take a while. If you have enough related objects, and the operation takes long enough, the browser may also stop waiting for a response and show an error. This would also be nice to address, but would likely be a far more difficult problem. The deletion would need to be an asynchronous operation which would mark the object as deleted (or hidden) so that Django Admin no longer shows it to logged in users, but it would have to run in the background until it is complete. Or perhaps instead of running in the background, it can tell the database to delete those related objects, and return without waiting to find out of the database succeeded? Just spitballing here. The solution would need to take into account things like: |
| | 29 | |
| | 30 | - Being compatible with WSGI, which may be using threads, or one of several async libraries |
| | 31 | - Being compatible with Django channels, which also probably impacts how background tasks run |
| | 32 | - The new Django 3 async efforts |