Refs #7181, add --include-year-archives and --force-optimize-tables options to purge-old-archive-data command. #7594
Conversation
…ptions to purge-old-archive-data command. First option includes january archive tables for dates supplied and second option forces table optimization even on InnoDB. Add parameter to Db::optimizeTables to force issuing a query.
diosmosis
added
the
Enhancement
Refs #7181, add --include-year-archives and --force-optimize-tables options to purge-old-archive-data command. First option includes january archive tables for dates supplied and second option forces table optimization even on InnoDB. Add parameter to Db::optimizeTables to force issuing a query.
| @@ -58,6 +58,8 @@ protected function configure() | |||
| $this->addOption('exclude-invalidated', null, InputOption::VALUE_NONE, "Do not purge invalidated archive data."); | |||
| $this->addOption('exclude-ranges', null, InputOption::VALUE_NONE, "Do not purge custom ranges."); | |||
| $this->addOption('skip-optimize-tables', null, InputOption::VALUE_NONE, "Do not run OPTIMIZE TABLES query on affected archive tables."); | |||
| $this->addOption('include-year-archives', null, InputOption::VALUE_NONE, "If supplied, the command will purge archive tables that contain year archives for every supplied date."); | |||
There was a problem hiding this comment.
I'm thinking that this should be the default, ie. always purge year archives for supplied dates. Is there a reason not to do this all the time?
There was a problem hiding this comment.
It would be confusing to the user if the january month ends up always being included.
There was a problem hiding this comment.
we care most about doing the correct thing - why would it be confusing to user to purge yearly archives? it seems to be implementation detail
There was a problem hiding this comment.
User runs core:purge-old-archive-data 2012-01-03 it purges 2012_03 and 2012_01. This is unexpected.
There was a problem hiding this comment.
The point of the command is to provide precision control for maintenance, it is not a one-click feature for end-users.
There was a problem hiding this comment.
Ok I'm not sure i'm getting it. I thought that if users have to manually purge year archives, it means the archive purger is not doing the job of purging year archives "automatically". so if we need this parameter in the console, I thought that the Scheduled Task itself which does not have this option, wouldn't properly invalidate yearly archives. But maybe i'm missing something so i may be wrong!
There was a problem hiding this comment.
For temporary archive purging, the scheduled task goes through every archive table, so year archives are affected.
For invalidated archive purging, the scheduled task uses the ArchivesToPurgeDistributedList, so if the year archive is invalidated correctly, the year table should get purged. I'm not very familiar w/ the invalidation code, though, just purging.
First option includes january archive tables for dates supplied and second option forces table optimization even on InnoDB. Add parameter to Db::optimizeTables to force issuing a query.
Refs #7181