Open jeffkinnison opened 4 years ago
I had originally designed deletion of texts as a one-at-a-time affair: https://tess-new.caset.buffalo.edu/docs/api/endpoints/texts-objid/#delete. This seemed most RESTful to me at the time.
Given how drastic an action this is, I continue to believe that one-at-a-time deletion is best.
So at present, my workaround is to fire off one delete request per text selected by the user. Would this enable concurrent deletion, and will it cause problems with the delete process on the API end? I foresee potential issues with deleting frequency data with concurrent deletion.
Glad you reminded me to update the delete function in the API code (it's still just doing a naive removal of the Text metadata from the database).
I intend to make the delete operation synchronous, so we shouldn't run into concurrency issues between delete requests.
As for frequency data being out of date while search is running, there's nothing preventing that. For now, I'll just assume that the user isn't running a search at the same time that texts are being deleted. Admin mode is available only in the standalone version, after all. And if the production server ever needs to delete texts, then we can bring it offline, run deletion, and then bring it back up.
Does that seem right?
Ok, I've updated the delete function (#47).
I'm thinking this endpoint just needs to accept a list of object_ids and return a response with an array of successfully deleted object_ids and a list of unsuccessfully deleted object_ids and the reason for failure (e.g., does not exist, something happened with the database, currently in use, etc.).
This one might be at /texts/remove/ or something similar.
On the frontend, I'll only expose texts currently in the database as well as a warning to users that they are about to take permanent, drastic action.