Jan, My gut feeling is that this ordering should be specified as undefined. The assumption being that users need to make sure their design docs don't rely on any given ordering.
Either that, or provide a mechanism for people to order their docs arbitrarily. I'd lean towards the first because its less complex, but the ordering the validations may be useful in certain situations. Though, ordering in terms of collation order seems like not a good thing to rely on. Paul On Sat, Jan 17, 2009 at 4:41 PM, Jan Lehnardt <j...@apache.org> wrote: > Hi dev list, Damien, > > I noticed when a database has multiple design docs with a > `validate_doc_update` function each. The validation functions > are called in the reverse string collation order of the design > document's id. > > The function in `_design/b` gets executed before the one > in `_design/a`, which comes before `_design/1`. > > The relevant code is in couch_db_update.erl: > > get_design_docs(#db{fulldocinfo_by_id_btree=Btree}=Db) -> > couch_btree:foldl(Btree, <<"_design/">>, > fun(#full_doc_info{id= <<"_design/",_/binary>>}=FullDocInfo, _Reds, > AccDocs) -> > {ok, [couch_db:make_doc(Db, FullDocInfo) | AccDocs]}; > (_, _Reds, AccDocs) -> > {stop, AccDocs} > end, > []). > > Reversing the order of design docs in the AccDocs variable is > easy. The question is which behaviour do we want or is there > a reason for the reverse-rule? > > Cheers > Jan > -- >