On Fri, May 27, 2011 at 1:43 PM, David F. Skoll <d...@roaringpenguin.com> wrote: > On Fri, 27 May 2011 13:07:06 -0700 > Chris Travers <chris.trav...@gmail.com> 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 ------------------------------------------------------------------------------ vRanger cuts backup time in half-while increasing security. With the market-leading solution for virtual backup and recovery, you get blazing-fast, flexible, and affordable data protection. Download your free trial now. http://p.sf.net/sfu/quest-d2dcopy1 _______________________________________________ Ledger-smb-devel mailing list Ledger-smb-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/ledger-smb-devel
