Add a cleanup function

Added a quick implementation using Cursor. I am not convinced the "just delete everything older than x" through the entity interface is a great idea. Especially if there is a large backlog I don't think it will finish in a reasonable amount of time. But maybe I'm mistaken, needs a little more testing (like with a prod database from my example project :) ).

As expected, this didn't go flawlessly, I ran into out of memory exceptions.

• I added a batching operation, deleting 100 log entries at a time, with an cache clear for the entity storage in between.
• I added a time limit, so the hook cron will not run longer than 10 seconds.

Typically, I would say this is enough for most setups. Maybe it is worth mentioning somewhere in the documentation that if you consistently get warnings that the time limit was exceeded, you need to either increase the frequency the cron hook is ran (maybe with a reference to ultimate cron) or reduce the amount of log entries created.

I just found 📌 Support OOP hooks Active and noticed there that currently most hooks are implemented using the OO class_resolver pattern, which makes the official OO hooks conversion much easier. So we should at least change that, possibly do it all in one go if 📌 Support OOP hooks Active lands first.

@eelkeblok: I have merged issue 📌 Support OOP hooks Active , so this functionality could be implemented with OOP hooks in mind.
Haven't reviewed the code yet, but described functionality looks promising :)

🙌 Excellent. I'll see if I can take a crack at that soon.

Refactored to use the new OO hook pattern.

Thanks for the MR. Logic looks good to me.
Only thing I'm wondering: couldn't we use a QueueWorker plugin to process the deletion of the stale log entries?
Then we wouldn't need the batch processing logic within the cron hook.
The processing time could be configured in the QueueWorker plugin - e.g. \Drupal\locale\Plugin\QueueWorker\LocaleTranslation has this set to 30 seconds.

I guess. We could create queue items that contain ID ranges to remove. Limiting the time spent on processing the queue is a built-in feature, so we wouldn't need to do that ourselves. We would loose the ability to report on the time limit being exceeded, which would be an indication that a system is producing more logging than can be removed. And we'd need to start to do some bookkeeping to prevent duplicate queue items being created, assuming the queue (and thereby the logging) hasn't been fully processed before the next time cron runs (which is a save assumption; why do all this, otherwise 🙂).

Or maybe I am missing something obvious and you had something else in mind 🙂

OK those seem like 2 valid points to stick with the current approach.
If the current logic would pose unexpected problems, we can still change the implementation later on.

Merging now.

Automatically closed - issue fixed for 2 weeks with no activity.