validation functions

[Jan Lehnardt <ja...@apache.org>]

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

Re: validation functions

[Chris Anderson <jc...@gmail.com>]

On Sat, Jan 17, 2009 at 1:49 PM, Paul Davis <pa...@gmail.com> 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 <ja...@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
>> --
>>
>



-- 
Chris Anderson
http://jchris.mfdz.com

Re: validation functions

[Paul Davis <pa...@gmail.com>]

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 <ja...@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
> --
>