Re: Conf: argue !

Hi

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

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.

Any other application accessing your data would do its own caching.

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

The SOAP application could be in Java/Perl/YouNameIt. It would create 
its own 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.

No, but there might be someone hacking in the database. We should catch 
those possible errors. This is all I wanted to say.

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

Why can't you guarantee that? Even in MySQL, you can create a "UNIQUE" 
typed key - eh?

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


Manuel