Hi Kartik
To some extent it depends on the size of the bulk.
For "small" numbers (e.g. up to 1000):
- you might want to design a task resource that takes an array of item IDs in its input and returns a correlated array of statuses in output.
- You need to consider whether you want "all or nothing" semantics, or rather you are prepared to accept partial failures.
For "large" numbers (e.g. greater than 1000):
- you'll probably prefer a job driven by a file or a stream of events
- the job will need to write statues to an output file or stream
In either case, consider the following:
- Managing referential integrity - if you delete an entity you may have "dangling pointers" (references) to a deleted entity so your software needs to be forgiving when trying to resolve such references
- Different statuses for failures to delete (e.g. entity not found, entity locked by another user, etc.)
------------------------------
Jonathan Goldberg
Amdocs Management Limited
Any opinions and statements made by me on this forum are purely personal, and do not necessarily reflect the position of the TM Forum or my employer.
------------------------------
Original Message:
Sent: Jan 13, 2023 01:19
From: kartik maringanti
Subject: Bulk delete operation
Hello Team,
I do understand that it is not recommended approach to go with the bulk delete option, as the control to delete should be done from the client in an iteration for each resource using DELETE /resource/{id}. But if given a requirement to bulk delete, what possible design guidelines can be proposed.
------------------------------
Kartik N Maringanti
Verizon
------------------------------