[OPEN-ILS-DEV] Rewrite of build-db.sh

[Dan Scott]

2008/7/15 Aaron Joyner <aaron at joyner.ws>:
> On Tue, Jul 15, 2008 at 9:05 AM, Dan Scott <denials at gmail.com> wrote:
<snip>
>> 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).
>
> Yeah, I saw the patch go in and thought briefly about it.  In general,
> the detection code currently isn't intended to come into play unless
> there *isn't* a version in place.  So, it won't adversely affect 8.2
> users at present, assuming they properly specify a database version,

Right - and that's the current assumption, so it was indeed an edge case.

> but if there are no major changes in version 8.4, you won't need to
> check in a file in the same way that 8.1 and 8.2 had their own
> duplicated version of the file.  On the other hand... that's not too
> future proof, it's really just intended to help as a "best guess to
> use the last version if one doesn't exist."  Note that it's also
> currently coupled with really big warnings.  :)

Saw those - I like your style :)

>> 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?
>
> I'll be glad to implement this additional sanity check.  Do you think
> it's worth it to remove the database specification from the user,
> detect the database version, and warn on a missing file?  I haven't
> looked widely enough to see if the database version is used for
> anything else in that build chain, my instinct is that can probably be
> torn out, and just auto-detected.  If that sounds good, I'll cook up a
> patch to do that, instead.

That sounds great to me.

> The more I think abou it, the fewer things the user has to enter
> (particularly in the current tediously long build/install process),
> the better.  I can't think of any reason why the user would want to
> specify a different database version at install time, unless he/she
> knows the contents of those scripts, in which case he/she's fully
> capable of working around the auto detection.  :)

I'm in full agreement with you. There are plenty of other "learning
opportunities" in the install process; the simpler and more robust we
can make this, the better.

Thanks again!

-- 
Dan Scott
Laurentian University