Re: Conf: argue !

> Hi
>
>> It's not an issue. The design says
>>
>>         //domain_name / section_name [/.......] / property_name => value
>
> This should be /domain_name... in my opinion - just a minor point.

yeah, // is xpath syntax for "select all matching name"

>> So it *clearly* does not allow for properties without a name.
>> Since arrays are not considered any more, your example is illegal:
>> this cannot be done within the design.

??

there are no "rules" and no such thing as "illegal" - this is a system we
have all designed for our own use. VERY rarely to we explicitly forbid
behavior (except in cases of ode style etc).

also, we need some form to handle arrays but we don't want to put
serialized arrays into the database because that is inelegant.

so manuel's example isn't illegal, it's a necessary extension which we
have all been discussing: how to handle putting arrays into the db
properly.

manual's last suggestion for a nested set is good just because it would
eliminate the need to have the /0  /1 thing on the end of paths: since all
nodes would have an explicit integer ID and parent ID it would be quite
easy to uniquely identify every element regardless of the presence of a
name.

however I am beginning to doubt the usefulness of doing conf in a DB that
is noy fixed and file based like a SQLite DB - because the problems
presented by introducting changes to a database table during a promote
process are nasty, and the whole promote process becomes MUCH more prone
to error.

>> Please note that in above example for '/smarty', the 'plugins-dir' moves
>> from a section into a property. Didn't see a comment on that 'feature'.

It can't. We need multiple plugin dirs, so we need a way to elegantly
represent an array. Obviously an XML file is an easy way to do that since
the syntax is pretty much built for multidimensional arrays.

> Duplicate ids are bad in my opinion. But that's only me, of course.

After seeing manuel's suggestion of a nested set and the point about
internal representation of keyless arrays in PHP, I agree. i.e. I would
much rather have a formal nested set or paths like:

/smarty/plugins_dir/0 ... /1

etc.

(or just XML again, heh (no one kill me!)

> I think that the current XML configuration format is good and we should
> allow the same structures in SQL, too.

I would corret that to "must" allow for the same structures.

> The point is what we want to allow as a query language. "Real" XPath is
> not the thing we want here, since you have to specify the namespace with
> each querying. Your example from above would become:
>
>      /conf:domain[@id='foo']/conf:section[@name='bar'] \
>           /conf:property[@name='rex']

> This is a bit complex.

not really :)

also we should standardize 'name' and 'id' I'll enter a ticket.

> Additionally, I do not think we need the "search the whole tree for a
> certain tag" feature of XPath. Something like the following is not
> required for configuration in my opinion:
>
>      //conf:property[@name = 'myname']

I agree. It would be pointless.

> I only gave some examples form XPath because it seems to be pretty
> complete for querying trees.

Yeah I considered (and may yet send) an alternate proposal which doesn't
use a database of any kind, and simply supports xpath and caching.

The good thing there is we keep XML with all the real "query" ability we
need, proper, known tools and speed w/ caching. XPath is VERY cool, and I
like using it.


>      $foo = $settings['bar']['foo'];
>      $bar = $settings['moo']['bar'];
>      foreach ($key => $value in $settings['bwahaha']) {}
>      for ($i = 0; $i < count($settings['whatever']['moo']); $i++) {
>          print "$i = " . $settings['whatever']['moo'][$i];
>      }

right.


> So I think that we should allow for numeric arrays and associative
> arrays. I think we need them for the following two reasons: First, you
> do not want to key (or can key) everything. Sometimes, you just want
> lists of strings. Second, we want to pass the configuration for
> datasources pretty rawly to the drivers - without having to write
> wrappers where we do not have to.

I don't think this is at issue - we must support both array types. Any
solution that doesn't allow for both can't be used.


>   * Do not allow querying beyond numeric arrays. This is not so big a
> problem as it sounds because in configuration files, you normally store
> a pretty flat list (2-4 levels at max from my experience) of values that
> you want to query for. These then have arbitrary structure, but you
> normally do not query within this structure. If anyone finds an example
> where he wants to query beyond a numeric array, please tell me. (Note: I
> do not take implementation into consideration at the moment, only the
> query "language")

Yeah I can't see when you would want to do that. Most numeric arrays
(keyless arrays) are contained in a section nicely.

>   * Allow to query beyond numeric arrays. This can be done by simply
> passing in the integer into the path: /domain/list/1/title. This is
> doable, but complex in implementation. However, let's do not care about
> implementation for now.

Yeah I don't see the point.

And I am increasingly not seeing the point of using SQL for something that
will work GREAT with xpath, be easy to implement (existing tools etc) and
all we would really need to do is add / change some methods in conf and
allow for caching. would be cool and simple.
_______________________________________________
dev mailing list
dev-PnctHDZWAvB/Cz2I37pSEPZ4XP/[email protected]
http://lists.binarycloud.com/mailman/listinfo/dev