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 <ja...@sigio.com > <mailto:ja...@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 >