couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Randall Leeds <randall.le...@gmail.com>
Subject Re: 160- failure
Date Fri, 25 Mar 2011 17:30:33 GMT
On Fri, Mar 25, 2011 at 06:13, Benoit Chesneau <bchesneau@gmail.com> wrote:
> 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
>

Just had the same thought.
001-local.ini ?
Might be a smart thing to do. Would there be any objections?

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