the FileOnDiskMixin.delete_from_disk_and_database method seems to cause regular issues, and the current implementation (delete from database then disk then archive) could cause some issues with the remove_downstreams flag that can be passed, which generally queries the database to find the objects to remove.
A more robust refactor seems worthwhile. My current idea is to implement a new get_downstreams_recursive function which will get all the downstreams and downstreams of downstreams of an object and return them as a list, then carefully go about deleting all the objects on that list in a proper order. This should solve the issue of querying the database after information has been removed, and will hopefully be more clear as to what is occurring in what order.
the
FileOnDiskMixin.delete_from_disk_and_database
method seems to cause regular issues, and the current implementation (delete from database then disk then archive) could cause some issues with the remove_downstreams flag that can be passed, which generally queries the database to find the objects to remove.A more robust refactor seems worthwhile. My current idea is to implement a new
get_downstreams_recursive
function which will get all the downstreams and downstreams of downstreams of an object and return them as a list, then carefully go about deleting all the objects on that list in a proper order. This should solve the issue of querying the database after information has been removed, and will hopefully be more clear as to what is occurring in what order.