Open Ashu96 opened 2 years ago
@Ashu96 let's say we introduce deleteAll()
method in the crud. Does it just iterate over entries and calls delete()
method internally which, as consequence, calls beforeDelete
and afterDelete
on each entry, or we introduce beforeDeleteAll
and afterDeleteAll
?
@brunozoric
The implementation should still have those beforeDelete
and afterDelete
lifecycle events because it will keep things consistent. Also, in my use-case other business logic depends on those events.
In regards to new beforeDeleteAll
and afterDeleteAll
, I'm in favour of those too even though I don't have an exact use-case for them.
100% agreed, it would be great to have a bulk delete entries action.
It would be neat to have in the UI as well. Currently, you cannot delete a content model if it still has any entries. Unfortunately, if you have hundreds of entries in that content model, you would spend an awfully long time going through all of them one by one. Checkboxes to delete all or select entries at once (kind of like in many other CMS) would be a game changer.
This issue is stale because it was opened 120 days with no activity. Remove the "stale-issue" label or leave a comment to revive the issue. Otherwise, it will be closed in 7 days.
Any news on this? Current workaround is to delete rows from DynamoDB in AWS ...
Thanks!
Is your feature request related to a problem? Please describe.
Lifecycle events are neat for building custom business logic on top of headless CMS. While working with a model with a
ref
field, I encountered a use case where, I needed to delete all those entries that are linked via theref
field.In order to do so, I had to write the code, which paginate through all those entries and delete them one by one. For example:
It would be a big help, if we have a
bulkDelete
operation in CMS which delete bunch of entries at once.We can also try extending this functionality for other operations like
create
andupdate
if possible.Describe the solution you'd like.
No response
Describe alternatives you've considered.
No response