Re: Conf: argue !

On 25 Feb 2005 at 14:18, Manuel Holtgrewe wrote:

> 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?

Let me explain (it's the other way around);

There is the remark 'no language specific data in the database, please'.
This is quite clear and understandable. It can be seen as a design 
constraint.
Next remark is that 'you'd rather use serialize()'; this in relation to 
caching the conf:values.
Now, I get confused on your intentions.

> 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.

Sure, sure, sure. But when config is cached the latest config is in the 
cache. That Soap thingie should read that cache.
One may discuss this; it's on the validity of config cache.

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

This is hypothetical. I'm sure there is a C++ routine to read php-
serialized data.
But BC might decide to allow editing of conf_values by BC_external 
sources. Start a discussion.

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

Completely true. There is full control. Overhead is cheap, isn't it?
Just kidding. Maybe we use a validator for this ? So we can reuse code?

> > 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.

Thank you for pointing me to the document. I didn't know that these 
concepts did become a name (surrogate and candidate).
I'm still convinced that you can't guarantee that the path is unique.
The software may whish that they are, but must react on path's not being 
unique. If the software can silently accept it, great: one constraint 
less.
But I would like to see *first* the solution to the errors in conf.xml 
generating properties without a name. Any discussion without that is 
humbug.

wim niemans