couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benoit Chesneau <bchesn...@gmail.com>
Subject Re: 160- failure
Date Fri, 25 Mar 2011 13:13:40 GMT
On Fri, Mar 25, 2011 at 1:22 PM, Jan Lehnardt <jan@apache.org> wrote:
> Good find Benoit!
>
> On 25 Mar 2011, at 11:01, Benoit Chesneau wrote:
>
>> Frome time to time the 160- etap test is failing (depending on the
>> platform or whatever). While chasing this issue I noticed that
>> returning values from couch_config:get inserted via couch_config:set
>> aren't in the right order:
>
> When designing the config system way back when I went with the assumption
> that order of sections or values in sections is not specified. I.e. CouchDB
> is behaving as "specified" (but I don't think I ever wrote that down).

sound normal. Thinking more about it I can't remember an example of
ini where order counts.

>
> It sounds like the wildcard vhosts rely on a specific ordering, is that
> correct? In that case, I don't have any problems guaranteeing the order
> of values within sections (but I wouldn't go so far as to define an order
> for sections themselves). Sections that are spread over multiple config
> files should take the order of when the subsequent files are parsed. I.e.
> Section X in file A and B orders its entries as all from file A and then
> from file B, if they are parsed in order.

>
> I'm fairly certain that the ini parser and writer also do not preserve
> ordering, which we'd have to look after.

Yes current vhosts rules like the rewriter are relying on the order.
It sounds really complicated to have this working with  multiple ini
almost impossible, except if they are prefixed I think

>
> Alternatively, can we make wildcard-vhosts not rely on the total ordering
> of config values?

It's easier to do. What doesn't work actually is the variable
replacement. I propose to remove these replacements and just use host
wildcard, simple path and host name. No wildcards in path. If we are
OK with that, I can attach the patch to jira during the we.

>
> Cheers
> Jan
> --
> PS: all the example urls in the previous mails in this mark this one as
>    spam for me, so I removed the previous trace.
>

Mime
View raw message