Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Subject: Re: 160- failure
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: text/plain; charset=us-ascii
From: Jan Lehnardt <jan@apache.org>
In-Reply-To: <AANLkTinGhzyu6uSi5u1W_JRiNiSQiJVgPi+6vzjYcZMA@mail.gmail.com>
Date: Fri, 25 Mar 2011 18:44:58 +0100
Cc: Benoit Chesneau <bchesneau@gmail.com>
Content-Transfer-Encoding: quoted-printable
Message-Id: <CA3AAB04-F7BC-42AB-A3A8-A41309E4F17D@apache.org>
References: <AANLkTimCzVijBEJrXX+waYv-CiKNfsLG2Fm_F6rLQX9X@mail.gmail.com>
 <82D29B2A-7F02-45E2-B1A6-99E8FBEC4BEE@apache.org>
 <AANLkTin6zRiiFtKZoFa60DRVyOcF1dXzMYtNdKuX=ZRw@mail.gmail.com>
 <AANLkTinGhzyu6uSi5u1W_JRiNiSQiJVgPi+6vzjYcZMA@mail.gmail.com>
To: dev@couchdb.apache.org


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!
>>>=20
>>> On 25 Mar 2011, at 11:01, Benoit Chesneau wrote:
>>>=20
>>>> 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:
>>>=20
>>> 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).
>>=20
>> sound normal. Thinking more about it I can't remember an example of
>> ini where order counts.
>>=20
>>>=20
>>> 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.
>>=20
>>>=20
>>> I'm fairly certain that the ini parser and writer also do not =
preserve
>>> ordering, which we'd have to look after.
>>=20
>> 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
>>=20
>=20
> 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
--=20


>=20
>>>=20
>>> Alternatively, can we make wildcard-vhosts not rely on the total =
ordering
>>> of config values?
>>=20
>> 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.
>>=20
>>>=20
>>> 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.
>>>=20
>>=20