Re: [Gnumed-devel] gnumed/client/etc/config-definitions/DBDefault.definitions vs. gnumed/sql/gmConfigData.sql

[Hilmar Berger]

Hi,

On Mon, 7 Feb 2005 14:16:17 +0100
Karsten Hilbert <address@hidden> wrote:

> > There seem to be two competing ways of defining config options.
> Nope. If I understand things correctly (Hilmar is the final
> authority) the *definitions* stuff is only used to define
> types and perhaps ranges for config parameters such that
> advanced config parsers/UIs can support context checking of
> user input without knowing anything about particular options.

Basically, the idea was that 
a) gmCfg/gmConfigData.sql supports only basic types (numeric, string, 
str_array) while we might want some higher-level types (like color, predefined 
ranges etc) later and 
b) the admin might not want to hack sql-files to change/add config options (at 
least I wouldn't)

So the solution was for a) to implement a possibility to define additional 
types (etc/config-definitions) and b) have a possibility to load config tables 
from an easy configuration file (see bootstrap/amis-config.set and 
client/pycommon/tools/set_conf-opt.py for an example). The problem that the 
description seems to be duplicated stems from the fact that at that time the 
majority of config options where not stored with any description (e.g. from 
within gnumed code at startup), so in order to have at least one description I 
duplicated this parameter. The type parameter does in the moment nothing the 
type field in the backend tables cannot do - but this might change if we want 
other types. 

So actually the duplication of functionality is something I wanted - although 
on a somewhat higher level than gmConfigData.sql. I'm not sure if it really 
what we need or if something should be changed/simplified. 

The workflow I imagined was 
1. you have some easy-to-use config-definitions, possibly containing default 
values that should be loaded at bootstrap/installation
2. these definitions contain information on type and possibly range of an 
config option that can be checked in the config editor

> If you just want to add some new option values go use
> sql/gmConfigData.sql and be done with it. If you want
Well, eventually we should have an installer that knows how to write config 
data from config definitions via set_conf-opt.py. This would be even simpler 
than changing gmConfig-Data.sql, especially if you want to store the same 
values for more than one user/machine pair.

The sanity checks are not completely imlemented, so there is still work to do. 

Regards, Hilmar