Epic
Minor What problem do we want to solve?
With current database level implementation of deletion:
- it can timeout if there are too many impacted documents
- deletion even are not backpropagated, potentially losing business consistency.
Same for trash service.
We need to have a 100% reliable way of deleting content in the repository whatever the number of impacted documents is. this way must become the standard one and be used: in Web UI, in the mobile application, in Drive and in client SDKs
Acceptance Criteria:
Given: a repository loaded with default initial content and trash feature enabled, web-ui deployed and two additional folders:
- one flat "Big flat" with 300 000 documents, none of them having the word "anticonstitutionnellement"
- one with 10 levels "10 levels" - 2 millions documents, upon which one document has the word "anticonstitutionnellement" in its title.
I go to the search tab and look for "anticonstitutionnellement". I find the only doc that is there.
I go to the "10 levels" folder and I delete it (it goes to trash).
I use the operation to fetch the working bulks. I see there is one running for poutting the 2 millions documents to trash
I keep calling the operation.
When the job is done, I go to the search tab, and search for anticonstitutionnellement. I find no document.
I go the trash search screen and search for "anticonstitutionnellement", I find the document.
As an admin, I click on "empty the trash".
I use the operation to minitor the bulks, I see the send to trash bulk.
When the bulk is done, I search again for "anticonstitutionnellement" and don't find it.
Then I go to the Big flat folder, and successively delete it (to trash), then empty the trash. I check after that that the trash is empty.
Resilience
--------------
Part of the previous scenario, but while the job 2 Millions documents is running, we kill the servers (aver. ll machines that are part of the setup). And start again the server. We should be able to continue the scenario.
