On Thu, Jan 9, 2014 at 3:36 PM, Liam Whalen <[email protected]> wrote: > >> 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? >
It is, and that means my assumption was correct. The titlesort value is stored as a record attribute and that's the majority of the logic directly in the trigger these days. > >> ... > >> 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. > Cool. I will make a note to revisit this thread once I've made a little headway on the new record attribute code. --miker > >> 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 -- Mike Rylander | Director of Research and Development | Equinox Software, Inc. / Your Library's Guide to Open Source | phone: 1-877-OPEN-ILS (673-6457) | email: [email protected] | web: http://www.esilibrary.com
