couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <>
Subject Re: 160- failure
Date Sun, 27 Mar 2011 22:20:26 GMT

On 25 Mar 2011, at 14:13, Benoit Chesneau wrote:

> On Fri, Mar 25, 2011 at 1:22 PM, Jan Lehnardt <> 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.

Sounds good to me. I created
to keep track.


View raw message