gnumed-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnumed-devel] Re: Bootstrapping for production -- user accounts


From: James Busser
Subject: Re: [Gnumed-devel] Re: Bootstrapping for production -- user accounts
Date: Thu, 06 Aug 2009 11:26:52 -0700 (PDT)

-----Original Message-----
> Am Donnerstag 06 August 2009 14:42:46 schrieb Karsten Hilbert:
> > On Thu, Aug 06, 2009 at 12:47:22PM +0200, Karsten Hilbert wrote:
> > Maybe it is clearer to ask: What about branches rel-0-3,
> > rel-0-4, rel-0-5 ?  Shall they all be enabled to produce a
> > "clean" GNUmed database ? If not that would mean
> > bootstrapping a v9 database from rel-0-4 will end up in
> > something different then bootstrapping v9 from rel-0-5. Is
> > that acceptable ?

The only difference will be in the detritus contained in older-branches, except 
where anyone would take the trouble to clean out the detritus themselves.

Back-patching clean-installs into the old releases will be extraneous for 
anyone who had already added production data.

Anyone who would *newly* start into production would almost certainly start 
with server v11, which could be patched even after the release of client 0.5 
(since a patch to enable a clean install would leave the schema untouched... it 
would alter just the scripts and data files).

Therefore new people could evaluate client 0.5 and server v11 even in advance 
of the "clean" option being ready. At the point where the new people would want 
to go into production, they could check if the clean option patch had been 
released and, if not, take their own decision on whatever manual cleaning they 
might wish to do.

Here is a question:

Based on the belief that, in the creation of a from-scratch GNUmed database, 
the bootstrapper always starts by creating v2 then -- if it is to deliver its 
promise of a clean install -- it will have to decide with each upgrade (v2 .. 
v3, v3 .. v4 ..) whether or not to include bits of test data that was provided 
with the expectation of showcasing incremental functionality.

Surely the upgrade scripts (the ones that are used to upgrade production 
databases) do not add test data to the production database, do they?

Therefore it would seem to me that if the bootstrapper currently uses some 
method (other than the upgrades) to go from v2 .. v11, maybe the bootstrapper 
should instead call the upgrade scripts, and only if the user had asked for 
test data, then GoTo a branch routine to load any data for that version, and 
then carry ahead to the next ..vN.

Maybe I came myself to exactly the current method, meaning that the problem of 
a clean database exists only at the first v2 phase of the bootstrapping?





reply via email to

[Prev in Thread] Current Thread [Next in Thread]