> Is your primary goal the ability to deal with record attributes and > conditionally pre-delete stale data? Other than that, everything is > fairly well factored out of biblio.indexing_ingest_or_delete(), so the > rest of this email will assume that ... If I'm wrong, please advise > and ignore what I say here. ;) >
This came about because Sitka wants to change our titlesort from using 245 $a to using 245 $a and $b. Once we make these changes, I am assuming we will need to run index_ingest_or_delete on all the records to have the titlesort change reflected across our catalogue. Is this correct? > ... > More generally, I don't particularly like the idea of teaching the > trigger to use parameters and then calling the trigger function > directly; but pushing the remaining logic that the trigger implements > into a regular function, and using params to /that/ function that the > trigger supplies by reading config.internal_flag values (turning the > trigger into a shell that sets up the default params), seems like a > good way to go. Passing blah%ROWTYPE objects for NEW and OLD into a > function is easy enough, and an HSTORE of flags for "do this, don't do > that" would allow for API stability as we add more ingest-y things. > I was not too keen on it either, which is why I wanted to find out if there were better options. I like the idea of having the trigger call other functions. That seems far more sensible to me. > On Thu, Jan 9, 2014 at 1:45 PM, Liam Whalen > <[email protected]> wrote: >> 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
