Re: State of Perl-based database setup utilities for LedgerSMB 1.3

[Chris Travers <..hidden..>]

On Fri, May 27, 2011 at 1:43 PM, David F. Skoll <..hidden..> wrote:
> On Fri, 27 May 2011 13:07:06 -0700
> Chris Travers <..hidden..> wrote:
>
>> Currently there are two approaches to installing databases in Perl.
>> The first (initiate.pl) has officially been moved to add-ons and is a
>> web-based interface for this process.  I have not personally used it,
>> although I have recently committed a lot of patches against it.
>
> I'm not sure I like a web-based interface.  This makes automated
> installations and testing much harder.

One reason that is an add-on.
>
>> The second approach is the use of makefile targets installdb and
>> installdb_interactive.
>
> I don't like that approach either.  I prefer an approach like this:
>
> 1) make
>
> 2) make install
>
> 3) ledgersmb-init-database
>
> That is, have a dedicated command-line script that initializes the database.
> It can be interactive, but should also take command-line options for a
> fully-automated setup of the database.  The ledgersmb-init-database
> script should do sanity checks to see if there's already a database, etc.
> If it does find a database, it can offer to do a schema upgrade (or
> do it automatically if so told by a command-line option.)
>
> This has the nice side-effect of making the upgrade procedure
> absolutely identical to the initial-installation procedure: make;
> make-install; ledgersmb-init-database.

In an upgrade you'd want to run all relevant production-safe tests on
your database right?  Wouldn't that require a test harness?

>
>> But this leads to the question:  do we want to depend on
>> perl test infrastructure and/or make utilities to be on systems we are
>> building databases from?
>
> I don't think it's a good idea to depend on those for systems on which
> we deploy.

Ok, getting rid of the requirement for make is truly trivial.  All we
really need to do is have a script which sets up environment variables
and runs prove against the appropriate db files, right?  That reduces
the dependencies to basically Perl's Test::More framework.
>
>> And given the amount of code in the
>> database, do we want to treat creating a new company database as a
>> build process or an administrative task for dependency and/or UI
>> reasons?
>
> Administrative task, for sure.  Otherwise packaging LedgerSMB as a .deb
> or .rpm becomes difficult.
>
Ok, that's a good argument for getting rid of a make dependency.
Again, I think that's pretty trivial to do.  However, on the back end,
that doesn't necessarily address how the command-line tool operates,
and what it requires to do it's job as far as the test framework goes.

Let's go over a hypothetical problem here......

Suppose LedgerSMB 1.3 is accidentally installed into template1 and
nobody notices.  Two databases are created... Everything works fine...
Upgrades come out... the database is updated and this involves
dropping a function and replacing it with one of different argument
types as well as some other schema changes made.  Later a third
database is created.  No tests are run.  The wrong function gets
called via automatic mapping functions, or the wrong data passed to
those stored procedures.  At this point, as far as the impact, all
bets are off but we might not hear about it for days, weeks, or even
months.  The current test cases would catch this problem.

We could document "we highly recommend you go into the
sql/modules/test directory and run all relevant files there" but I am
wondering if we really should run automated tests on the database
after it is set up.

Best Wishes,
Chris Travers