2008/7/15 Aaron Joyner <[EMAIL PROTECTED]>: > The attached patch is a rewrite of build-db.sh. I originally intended to > just make it gracefully handle missing files, but I got on a roll. A break > down of changes, by bullet points: > - validate that the fts-config.sql script exists for the specified database > version > - if it does not, detect the latest available version, warn the user, > suggest aborting, offer to continue w/ the latest available version > - rework call of psql to avoid PGPASSWORD on the command line, visible via > ps > - warn user if psql fails attempting to import any of these files for > reasons such as couldn't connect, or file not found (not sql script errors) > - provide commented out option to fail on sql script errors, for future > convenience when the scripts run cleanly w/o errors > - limit line length to 80 characters (a nearly unbreakable habit from work) > > There aren't a large number of shell scripts in the depot, the only thing > which had a sufficiently large amount of style to go by was > Open-ILS/examples/oils_ctl.sh. I adopted that commenting and indenting > style, if that's not an appropriate example, please provide suggestions or > pointers to a style guide. oils_ctl.sh is a bash script, but build-db.sh > originally defined #!/bin/sh, so I opted to avoid the few bash style > elements from oils_ctl.sh that caught my eye (function foo()..., for > example), and leave it as a /bin/sh script, figuring it's better for > compatibility. > > I've endeavoured to follow the submitting doc as closely as possible > (http://open-ils.org/documentation/contributing.html#Submitting%20a%20Patch), > but if I'm missed anything, or you require any additional information, just > let me know. > > Thanks for the interesting project! I look forward to contributing more > code in the future. > Aaron S. Joyner >
Hah! This is really great, Aaron - I've thought about overhauling build-db.sh a few times but never given it a go. Sadly, we may have a bit of a collision in one small area, as I committed an initial PostgreSQL 8.3 full text search schema to trunk about 8 hours ago - so if a user doesn't specify a PostgreSQL version for your script, they'll get 8.3 (and probably suffer ignominous failure). The approach I had been thinking about was using the database credentials to do an initial login to the database to grab the server version (SHOW server_version or SHOW server_version_num, whichever is easier to parse) and use that to take the decision out of the user's hands. Or at least provide a sanity check. Would you be interested in taking a crack at refining your patch in this fashion? Thanks a ton, Aaron (even if you decide not to tackle that)! -- Dan Scott Laurentian University
