Re: Conf: argue !

On 26 Feb 2005 at 1:02, Manuel Holtgrewe wrote:

> Hi
> 
> > 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.
> 
> I wanted to say "use serialize for caching". Serialized data should not 
> go directly into the database. For caching this is no problem since the 
> only code that will read the cache will be binarycloud and thus PHP based.

Yes, I did understand that. I did acknowlege before that I agreed in 
avoiding language-specific data in the database.
As a matter of fact I do not see a difference between the cache and the 
database. But that is solely archtectural. So my conclusion would be: do 
not use serialize(). Hint: in a load-balanced environment the cache would 
be stored into a database, wouldn't it?
Than, as a second argument, but not necessarily discussable, I do think 
that, say, binary data for a configuration is a good way to protect for 
hacking.

> >>>You will need an 'id' when updating, since you can't guarantee that a path 
> >>>is unique. Stronger, a unique integer-id is required.

<snipped>

> > 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.
> 
> Why can't you guarantee that? Even in MySQL, you can create a "UNIQUE" 
> typed key - eh?

No, no. This is *not* what I ment to say.
The desired unique path can be guaranteed. This doesn't need me in person.
However. However. In the design of BC the defined path is *not* unique.
So, please read 'We can't guarantee that the path is unique' as 'The design of BC doesn't allow for unique paths'. I've coped with that in the draft, saying we need an integer as PK.
The xml definition allows for properties without a name_attribute. This 
generates non-uniques paths.

> > 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.
> 
> What do you mean with this?

Please look at smarty.(dist).conf.xml, auth.conf.xml and debug.conf.xml and find there properties with no name attribute.
Offcourse this can be solved. The issue is 'do we allow for arrays', which (when agreed upon) introduces some customized data format. This refers exlusively to the database, *not* to xml and/or php.

wim niemans.