The extract commands will usually be the very last operations that will get executed, since the extraction is usually done in an afterCommitHook. Because the extract handler doesn't support atomic updates, it needs to include all the fields again in full.
The collection of that data is however performed much earlier, at the time when the extract command is queued. For new objects created in the very same request, this means that the time those metadata fields get read from the object might be too early.
In the case of the bumblebee_checksum in GEVER, the following seems to happen:
The extract command gets queued. get_data returns None for bumblebee_checksum because no file is present yet.
That data dict gets queued in ftw.solr together with the extract command
In between, the bumblebee_checksum gets indexed into Solr with the correct value
But at the end of the request, the extract handler will overwrite (remove) it again because it's called with the data that was built before the file existed
The extract commands will usually be the very last operations that will get executed, since the extraction is usually done in an
afterCommitHook. Because the extract handler doesn't support atomic updates, it needs to include all the fields again in full.The collection of that data is however performed much earlier, at the time when the extract command is queued. For new objects created in the very same request, this means that the time those metadata fields get read from the object might be too early.
In the case of the
bumblebee_checksumin GEVER, the following seems to happen:get_datareturnsNoneforbumblebee_checksumbecause no file is present yet.datadict gets queued inftw.solrtogether with the extract commandbumblebee_checksumgets indexed into Solr with the correct valuedatathat was built before the file existed