[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