[OPEN-ILS-GENERAL] Marc field change script

Jason Stephenson jason at sigio.com
Tue Apr 7 09:12:00 EDT 2020


It is personal preference.

I agree wholeheartedly on creating your own, custom schema for
nonstandard things. We've got a schema called cwmars for custom
functions, views, and tables that we use in some local processes.

I've also added a schema called backstage to use exclusively with our
quarterly bibliographic/authority updates from Backstage Library Works.

On 4/7/20 9:03 AM, Rogan Hamby wrote:
> To me, and this is personal preference I think, I don't see a big
> difference between writing something once outside the db versus in it. 
> Both approaches are fine in my mind.  It does make me think of a point I
> didn't mention though, which is I wouldn't store a function in any
> existing Evergreen schema.  If you do make your own functions for tasks
> like this create a distinct schema for them along with any tables.  I'm
> not a fan of mixing project stuff into the stock schemas.  
> 
> 
> 
> On Tue, Apr 7, 2020 at 8:45 AM Jason Stephenson <jason at sigio.com
> <mailto:jason at sigio.com>> wrote:
> 
>     Glen & Rogan,
> 
>     I prefer to do these things outside of the database, i.e. pull the
>     record out with DBI, modify it, and then update it with DBI.
> 
>     I'm not a fan of writing database functions for something that I'll use
>     only once or twice.
> 
>     I have some utility scripts that I've used and shared with the world
>     available on Github:
> 
>     https://github.com/Dyrcona/evergreen_utilities/tree/master/perl
> 
>     A couple of those might prove useful as examples, possibly
>     loaderecords.pl <http://loaderecords.pl>.
> 
>     My pre-conference presentation last year covered getting started writing
>     utility programs in Perl using the Evergreen back end. The files for it
>     are also available on Github:
> 
>     https://github.com/Dyrcona/evergreen2019-preconference
> 
>     I hope that you find the above to be useful, and if you have more
>     technical questions, the conversation should probably move to the
>     development list.
> 
>     Cheers,
>     Jason
> 


More information about the Open-ils-general mailing list