When indexing big data, indexing happens in batch processes. For each process the request time changes and could be hours later when the last process runs.
For some integrations it is important to know the time when the indexing was requested.
For example the default content deploy wants to set the same export timestamp on all items that belong to a batch.
(That is important for incremental imports.)
Optionally store the request timestamp within the index as property so that backends can access it.
Within batches,the index gets serialized including the timestamp.
Show commandsStart within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
changes
Comments
Comment #3
mkalkbrennerComment #5
drunken monkeyLooks good, and seems small enough of a change to be acceptable even if it probably won’t be useful to more than a few people/modules.
I made some minir changes to the MR, please review. Also the newly adapted test is failing, my guess would be that the index instance use in the indexing batch is not the same as in the test method.
If you can think of another quick way to test the new method, that would be great, but otherwise I’d say it’s also no big deal if there is no test coverage, as long as you’re confident it works as desired (as the main user of the new method) and think it’s unlikely it will ever break due to some changes in Core or our batch indexing code.
Comment #7
drunken monkeyMerged.
Thanks again!