[OPEN-ILS-DEV] Proposed changes to indexing_ingest_or_delete

[Liam Whalen]

> 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
> <liam.whalen at bc.libraries.coop> 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