I would like to modify the trigger function indexing_ingest_or_delete, but I am not certain if my planned changes are the best option.
I have created a bug report and added my proposed changes as a document attached to the report. The bug report is here: https://bugs.launchpad.net/evergreen/+bug/1267566 I have also attached my proposed changes to this email. Any suggestions or alternate approaches would be appreciated. Liam Whalen BC Libraries Cooperative - Sitka Systems Specialist 855-383-5761 x1022 [email protected]
Plan for modifying indexing_ingest_or_delete for parallel ingest Currently, Jason Stephenson has a script that will ingest bib records in parallel. It does this by calling metabib.reingest_metabib_field_entries with different parameters, so browse only ingests can occur in serial while other ingests can occur in parallel. I would like to modify the script, so it can use the other logic from indexing_ingest_or_delete, but call reingest_metabibi_field_entries from within indexing_ingest_or_delete with the needed parameters when running the script. To do this, I plan on adding parameters to the indexing_ingest_or_delete trigger function. One parameter would allow the code to distinguish between the type of ingest needed. The other would contain a biblio.record_entry.id. With these parameters, the parallel ingest script could call indexing_ingest_or_delete directly. By calling indexing_ingest_or_delete directly from the script, the logic does not have to be maintained in two places. Normally, when the trigger function is called on an UPDATE, the variables NEW and OLD contain the record that was updated in its new and old states. As well, there is a TG_OP variable currently used in the trigger function to determine if the transaction was an UPDATE. The new id parameter would be used to populate the NEW and OLD variables within the trigger by selecting the bib record into the variables. TG_OP would be hard coded to UPDATE in the case of a parameter being present. Hopefully, these modifications can be contained at the top of the code, and the rest of the logic can be left alone. However, depending on whether or not I can actually modify the NEW, OLD, and TG_OP variables, I may have to use different variables and add IF statements or extra conditions to current IF statements to get this to work. I believe this is a better solution then pulling the current logic out of indexing_ingest_or_delete and adding it to the parallel ingest script. But, I am not sure if there is a better solution to what I am proposing. As well, I do not know if the other actions in indexing_ingest_or_delete can be performed in parallel. It appears to me that they could be, but I am not certain.
