On 25 Mar 2011, at 18:30, Randall Leeds wrote: > On Fri, Mar 25, 2011 at 06:13, Benoit Chesneau <[email protected]> wrote: >> On Fri, Mar 25, 2011 at 1:22 PM, Jan Lehnardt <[email protected]> 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. >>> >>
