Background
CMS heavily relies on CRUD operations for IContent. And therefore there are Content Events for single item operations.
And then subscribing tasks such as Search&Navigation Indexing and other event subscribers also reacts on every individual Content Event.
Long running scheduled jobs (that runs many hours) that Creates/Updates/Deletes/Moves IContent is bombarding the DB for every single action.
Request
One missing feature in CMS is the support of bulk actions for IContent.
Take the example of the long running scheduled jobs (that runs many hours) that Creates/Updates/Deletes/Moves IContent and is bombarding the DB. Another approach could be more like the Entity Framework, just making state changes and when all changes are done (in that context), just commit the changes to the DB in one large bulk request (at least in an API point of view, what is optimized under the hood is the product owners responsibility).
If adding such feature/API:s to update an bulk of IContent, then there could be bulk Content Events, and then content event subscribing features could react when all bulked actions is being completed.
What to gain in the short terms
An API that supports bulk actions would immediately show intents of bulk usage. Custom event subscribing could listen and act on native implemented bulk events instead of work around logic.
What to gain in the long terms
It would put bulk actions on the CMS roadmap, while still being useful in the event subscribing aspect, it would be possible to safely, over time, optimize underlying internal implementations and integrations, like lower the number of individual operations to various integrations. Given the database design there wouldn't possibly be a great performance gain in doing bulk operations in current state, but it would point out a direction where you in the future could find a path where you could do optimization to lower the number of DB-requests and make bulk updates in DB-calls too, removing an infrastructure bottleneck, improving stability over time.
