Re: [Gnumed-devel] Configuration options

[Hilmar Berger]

> On Mon, 19 Apr 2004 20:27:29 +0200
> Hilmar Berger <address@hidden> wrote:
> 
> > client/pycommon/tools/transferDBset.py -i yourOptionFile.
> Can yourOptionFile be the same as 
> /gnumed/client/etc/config-definitions/DBDefault.definitions
> The only difference seems to be transferDBset allows a default value.
> Otherwise each new value
> has to be specificied in 2 different places.
This is possible and IMO a good idea if you want to set default values at
installation. The time I wrote this code, default values where usually set
from within code or depended on other options (e.g. the drug database you
want to install). That's why there are two separate files. However, we could
add default values for options where this makes sense. As far as I remember,
this is already implemented somewhere in gmConfigCommon.
> 
> I must admit I struggle to understand why this is so complicated. Why
> can't cfg_template be populated from
> a .sql schema file like all the other backend tables are? Then the config
> editor can use cfg_template.description, 
> it doesn't need it's own files.
I agree that there is some duplication regarding description. I disagree as
to put the data in sql schema files. IMHO changing default options is
something that should not be too hard even for the unexperienced admin/user.

Hacking SQL files is definitely more difficult than changing a textfile. In
general I tend to believe that data that is not static and might be subject
to changes by the user/admin should not be set from withing SQL files. 

Imagine an admin that has to change/add some options for different users in
the backend after already installing the server. In the current
implementation, you write/edit the options-file, run transferDBset -i -u
User optionFileName  for every user - that's all.

In the case of SQL files, you will have to write/edit an SQL file, where you
will either have to write either INSERT or UPDATE, depending if the option
already existed (you will have to look that up). Plus you have to set the
user name etc. by hand for every option. In short, you will have to write
all the SQL code in gmCfgSQL.set() to get it right. 
And you say that editing SQL files is less complicated ?? Even in the case
of editing defaults before bootstrapping I would prefer the plain text
version.
There might be room for improvement of the current solution, but dropping it
in favour of plain SQL IMHO is not a good idea.

Hilmar


> Ian
> 
> -- 
> PGP public key E750652E at wwwkeys.pgp.net
> 9BF0 67B7 F84F F7EE 0C42  C063 28FC BC52 E750 652E
> 

-- 
NEU : GMX Internet.FreeDSL
Ab sofort DSL-Tarif ohne Grundgebühr: http://www.gmx.net/dsl