Re: Conf: argue !

Wim Niemans ri schrieb:
> On 24 Feb 2005 at 18:45, Jean-Christophe Michel wrote:
> 
> 
>>Manuel Holtgrewe wrote:
>>
>>
>>>I like the idea of "core settings cannot be changed on the fly"... And 
>>>what about people who do not have a database?
>>
>>They'll have to put their conf values in xml and call 
>>tools/cli/reload-confs.php instead of tools/web/reload-confs.php :-)
> 
> 
> So, the proposed method myConf->set(path,value) shoud evaporate than?
> 
> Having an install script for a conf is a good idea. Same goes for 
> translated language packs.
> 
> 
>>>>How ? I'd propose to use a var_dump of all confs and simply include 
>>>>this php file. It would be regenerated on each change in confadmin.
>>>
>>>Yes, this is what I meant, but I'd use serialize(). However, things 
>>>could be changed through some sqlite tool and you'd have to check for 
>>>that kind of changes.
> 
> 
> From a previous message on this list:
> 
> 
>>Ugh - no serialized data in a DB please. Cache to be fast, but use nice
>>types that are not language specific.
> 
> 
> Is this serious?

As serious as you will see me. Have you ever wondered what happens if 
you build a database driven application and you either want to replace 
the application code by something not written in PHP - or maybe a more 
or less incompatible version of PHP?

For example, consider you built a CMS and sold it. Now, you or a custom 
er of yours want to add a SOAP interface to allow a native (in the sense 
of C++ & Windows API/C++ & Gtk etc.) frontend to edit things. If you 
have serialized arrays in there you have a problem. If you behaved right 
and have a nice schema, all the stuff in the database is perfectly editable.

To put it in a nutshell: What happens if the data outlives the application?

This is not that a big problem for configuration, but I'd rather keep 
all the things in binarycloud that access databases consistent and 
clean. It's not a big price you pay: Simply a row per configuration. And 
exploding is not hard as you lined out.


>>I mean that we can check bad names in conf when rebuilding the cache.
>>No need to wait for running the site.
> 
> 
> Check for bad names? What's the definition of a 'bad name' ?
> To my humble opnion conf can't check nothing while loading.

Uhm, how so? Conf is written in PHP and you have full control over that.


>>>>property::path should already be unique. Of course this makes a long 
>>>>pkey, but since all db is cached into a php array, why have a numeric id?
>>>
>>>Because you might decide to shift things and path is volatile in this 
>>>respect. However, you are right, id is a candidate key - a *possible* key.
> 
> 
> You will need an 'id' when updating, since you can't guarantee that a path 
> is unique. Stronger, a unique integer-id is required.

Of cource you can guarantee that. Simply add constraints on it. A unique 
integer id is a surrogate key (sorry for writing about it being a 
candiate key earlier); see http://tinyurl.com/4ar9h.


Manuel