So, the usage of HTMLCacheUpdateJob would require the pageId, nsId and title dbkey of the title on the remote wiki to be known when constructed.
The LocalJobSubmitJob is run on a single wiktionary and fires CacheUpdateJobs out to the other wikis.
This means that we can not make a HTMLCacheUpdateJob directly within the LocalJobSubmitJob as we do not know the pageid of the page on the other wiki.
- Do a lookup of the pageid on the remote wiki within our LocalJobSubmitJob, this seems a bit ugly :/
- Keep our CacheUpdateJob (maybe rename it) and make this submit another HTMLCacheUpdateJob. This means there is an extra job in the chain :/
- Keep our CacheUpdateJob and call the construct and run the HTMLCacheUpdateJob from within!
- CacheUpdateJob update the page_touched field? This doesn't solve what was mentioned in the review ticket regarding ease of forward compat with core caching
- Extend HTMLCacheUpdateJob and override the run method and constructor. This would allow us to pass in the title that we know and do the pageid lookup later in the job.
- Change HTMLCacheUpdateJob to be able to purge titles without requiring the pageid
2.A seems about right..