couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: 160- failure
Date Fri, 25 Mar 2011 17:44:58 GMT

On 25 Mar 2011, at 18:30, Randall Leeds wrote:

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

Yeah, it looks ugly and it doesn't help solving the problem :D

This is about couch_config not preserving order, not about the order of insertions into couch_config
:)

Cheers
Jan
-- 



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