On Sat, Jan 17, 2009 at 1:49 PM, Paul Davis <[email protected]> wrote: > 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.
Agreed. Each validation should stand on its own. > > 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 <[email protected]> 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 >> -- >> > -- Chris Anderson http://jchris.mfdz.com
