Re: Wim's Conf Proposal

On 19 Feb 2005 at 16:07, Jean-Christophe Michel wrote:

> Wim Niemans ri wrote:
> > The new configuration draft (short version) has changed in it's definitive 
> > form.
> > Read it at http://tinyurl.com/4evlt
> 
> Good.
> Can you plz give example where this '*' syntax is useful ?

Sure.
1. Having wildcards does *not* mean you have to use them.
2. If we agree on some standards in configuration options:
f.i. some applications use '[debug]' as section
*than* you may use '/*/debug' and find all things that are debugged.
f.i. some applications use '[options]' as section
*than* you may use '/*/options' and find all things that are optional.
f.i. some applications use '[datasource]' as section
*than* you may use '/*/datasource' and find all things that are coming 
form 'outside'.

BC could decide to define a few standard config_values_parameter_names.
Or a naming convention for sections. Well, just a thought.

It does not have to be usefull, but it could.
If the draft is better without the wildcard, I'll remove it gladly.

> 
> I'm afraid of costly qries in db for such paths:
> 
> > 'smarty/*' === 'smarty' are equivalent
> 
> Most efficient sql: WHERE LEFT(path,6) ='smarty'
> 
> > 'smarty/par*' retrieves smarty/parameter_1
> >                     and smarty/parameter_2
> 
> Most efficient sql: WHERE LEFT(path,10) = 'smarty/par'
> 
> > 'smarty/par*/options' retrieves smarty/parameter_1/options
> >                             and smarty/parameter_2/options
> 
> I don't see sthg else than WHERE paht LIKE 'smarty/par%/options'
>    * is it standard sql (postgres? sqlite?)
>    * isn't it too long to run
>    * such qries cannot be cached efficiently

I don't know about performance. I do know that one uses a wildcard in 
exceptional cases.

Cheers,
wim niemans