Open Kevin-Hamilton opened 2 years ago
Or maybe it could be by action count? So keep the last 1000 actions or something. Not familiar with the code so not entirely sure that'd work.
Sounds OK to me, but I don't think the LIMIT clause can be applied to a DELETE in MySQL for a multi-table delete, so it might complicate the delete a bit. You could probably do it through multiple queries by creating a temp table of the post IDs to be deleted and then joining your delete to that.
I was also thinking that regardless of how the garbage collection is configured on the WordPress side, it would make sense to communicate that garbage collection information back over to the gatsby-source-wordpress plugin so the gatsby build process can compare its cache to that garbage collection information and decide if it is within the garbage collection period, or needs to purge cache and just request all the data fresh from WordPress.
Right now, the action_monitor garbage collector is hardcoded to "-7 days":
https://github.com/gatsbyjs/wp-gatsby/blob/master/src/ActionMonitor/ActionMonitor.php#L383
I would like to request that this be configurable, ideally through plugin settings in wp-admin, or at a minimum through a WP filter hook or a constant that could be defined in the theme or in the wp-config.php.
My use-case: We have infrequent updates to our website ... perhaps 2-4 per month. We have 5 different developers any one of whom may be asked to run a build of our website after content updates in WordPress. Each developer has a local copy of gatsby where they would build and then deploy the site from. If one developer runs builds the first and second week of the month, and then a different developer runs a build on the third week of the month...The garbage collector has removed the first two updates, and so they exist only in the first developer's gatsby cache ... The second developer only receives the updates from the past week and the updates from the first two weeks of the month disappear off the website.