[OPEN-ILS-DEV] Functions for updating the call number label or owning_lib associated with a copy

[Dan Scott]

On Thu, Apr 14, 2011 at 09:59:50AM -0400, Galen Charlton wrote:
> Hi,
> 
> On Apr 14, 2011, at 9:36 AM, Dan Scott wrote:
> > I would probably just bash out something like:
> > 
> > UPDATE asset.call_number SET label = 'MYS ' || label
> >  WHERE id IN (
> >    SELECT acn.id
> >      FROM asset.call_number acn
> >        INNER JOIN asset.copy ac ON ac.call_number = acn.id
> >        INNER JOIN asset.copy_location acl ON acl.id = ac.location
> >      WHERE acl.name = 'Mysteries'
> >  ) AND label NOT LIKE 'MYS %';
> > ;
> 
> Which is fine as a one-shot; what Ben's proposing is more generally useful.

Generally useful if documented and tested and maintained, perhaps.

> > I'm not sure we have many utility functions defined as part of the stock
> > schema that are intended to be invoked directly by humans, rather than
> > to support the application. To date, most of these things have lived in
> > the wiki (ye olde "Magic spells") and have had a corresponding level of
> > support. 
> 
> And in same cases could stand to have a better level of support.  Needing to change call numbers en masse is a very common situation; having some utility functions in the database to do certain types of maintenance the Right Way, for various values of "Right Way", would be useful even if they don't necessarily have an exposed UI yet.

I acknowledge that they could be useful, as above.

> That said, such utility routines can easily live in another schema.  Since we've just about finished going through the pain of adding a new schema, shall we just stick such functions into 'evergreen', or is it worth defining yet another schema?

You snipped out the concerns I expressed about testing and maintaining
these functions. Say what you will about the state of testing of the
existing database functions, at least there's a chance that they will be
exercised and deficiencies noted in day-to-day operation, as they are
part of the general code. For the class of functions that Ben is
proposing, however, I personally wouldn't want to see them become part
of core unless there is a solid plan in place for documenting and
testing and maintaining the functions; these seem much more likely to be
susceptible to bitrot.