Re: [Gnumed-devel] bootstraping v19 without starting from v2

[Busser, Jim]

On 2013-11-12, at 7:02 AM, Karsten Hilbert <address@hidden> wrote:

> On Tue, Nov 12, 2013 at 03:49:21PM +0100, Hilbert, Sebastian wrote:
> 
>>>> Is it technically feasible to make v18 the new v1 ?
>>> 
>>> Yes. But it would be extremely stupid.
>>> 
>> The argument always seems to be the user is not supposed to boostrap anyway 
>> and it is a once in a lifetime job and last but not least ideally all it 
>> takes 
>> is one password prompt.
> 
> That argument got nothing whatsoever to do with whether
> it is a good idea to make v18 the new v1 (regardless
> that is is technically quite possible).
> 
> Karsten

I am thinking to put, onto the mini-projects list, to clean out from a demo db 
as many values as can be deleted from a db intended to be used for production 
and then making a dump available.

In the case where some items might have been useful to keep (say, some document 
templates) they could always be extracted from some other instance of a demo 
database from a test machine.

A few questions in contemplating such a mini-project:

1) as far as server sql files, are the country-specific files are the 
country-specific files all bootstrapped, regardless of the country where GNUmed 
is being bootstrapped, in order to create a fully-loaded GNUmed database?

2) are the country-specific files intended (and properly capable) to be run 
only during an early stage (v1, v2) of a bootstrap, or are these intended to be 
able to be run at any later time?

3) are the sql files which live at the first level under 'server' all run as 
part of creating v1 or v2 and therefore unintended to be reliably runnable at 
any later time?

4) presumably all users (except any-doc) can be safely removed, while 
preserving any-doc mainly for the convenience of whoever would more fully set 
up GNUmed in the praxis

5) what table entries, if deleted, will risk to cripple GNUmed?

Safe for deletion should be all of the patient data, which would require to 
first delete all data which links back to the persons, and then finally 
deleting the test persons' names and identity records

        measurements
        hospitalizations
        procedures
        medications
        allergies
        occupations
        documents
        vaccinations
        family history
        notes
        encounters
        episodes
        waiting list items
        inbox entries
        invoices
        billings
        demographics
        names
        identities (except McCoy)

but then comes the question of what else might be desirable to purge.

Things like encounter types, addresses, organizations, consumable substances 
and branded drugs, codes and terms … basically any combination of items in

        GNUmed > Master data > Manage lists

except that it could be desirable to keep some items, like generic vaccinations.

And then, once all tables have been fully enough culled, to zap everything 
residing in the audit tables.

What I am wondering is whether there are tables in GNUmed (other than users) 
which cannot be empty or else GNUmed will be borked, or will at least refuse to 
run until at least one row is added and populated through backend tools. Maybe 
each of the reference tables (encounter types. comm channels etc) will all 
need, or at least be good to have, at least one value before the GUI will be 
usable.

Are there any wisdoms or suggestions on this?

-- Jim