couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: [jira] Commented: (COUCHDB-196) Bug in _all_docs: extra incorrect row returned when ?key= is specified
Date Fri, 09 Jan 2009 12:32:49 GMT
Adam,

   I'm not sure it is identical though it looks to be. I definitely  
would replace it as you suggest if only to simplify the code. I just  
posted this to give Chris a place to start and hopefully something  
towards the answer. I'm sure sure there are not other places that  
also need to change.

   Thanks for noticing those glitches in the test cases, I was so  
thick in it I wouldn't have thought my solution was exposing  
something there, I just assumed I was wrong. Can't beat eyeballs

    It's a very nice piece of Elang code. I'm enjoying learning it.

Cheers,

Bob


On Jan 8, 2009, at 10:36 PM, Adam Kocoloski (JIRA) wrote:

>
>     [ https://issues.apache.org/jira/browse/COUCHDB-196? 
> page=com.atlassian.jira.plugin.system.issuetabpanels:comment- 
> tabpanel&focusedCommentId=12662235#action_12662235 ]
>
> Adam Kocoloski commented on COUCHDB-196:
> ----------------------------------------
>
> Hi Bob, thanks for looking into this.  I'd argue for replacing that  
> entire function with couch_view:less_json/2
>
> diff --git a/src/couchdb/couch_db_updater.erl b/src/couchdb/ 
> couch_db_updater.erl
> index 049a354..38885f8 100644
> --- a/src/couchdb/couch_db_updater.erl
> +++ b/src/couchdb/couch_db_updater.erl
> @@ -253,13 +253,8 @@ init_db(DbName, Filepath, Fd, Header0) ->
>      Header = simple_upgrade_record(Header0, #db_header{}),
>      {ok, SummaryStream} = couch_stream:open 
> (Header#db_header.summary_stream_state, Fd),
>      ok = couch_stream:set_min_buffer(SummaryStream, 10000),
> -    Less =
> -        fun(A,B) when A==B -> false;
> -        (nil, _) -> true; % nil - special key sorts before all
> -        ({}, _) -> false; % {} -> special key sorts after all
> -        (A, B) -> A < B
> -        end,
> -
> +    Less = fun couch_view:less_json/2,
> +
>      {ok, IdBtree} = couch_btree:open 
> (Header#db_header.fulldocinfo_by_id_btree_state, Fd,
>          [{split, fun(X) -> btree_by_id_split(X) end},
>          {join, fun(X,Y) -> btree_by_id_join(X,Y) end},
>
>
> The DB behavior seems to be the same either way, and the fewer  
> places we have this collaction algorithm coded up the better.  I  
> looked into the 2 test suite failures that show up as a result of  
> applying either of these patches.  The failure in design docs  
> occurs because the test suite expects to find the document "_design/ 
> test" in the _all_docs view between "_design%2F" and "_design% 
> 2FZZZ".  That expectation is erroneous.  I'm not sure why it worked  
> before.
>
> The second failure occurs in view_include_docs where an _all_docs  
> view is queried with limit=2&skip=1.  In the trunk code _design  
> docs sort after docs with stringified integers for ids.  Your patch  
> causes the _design docs to sort first, which I believe is the  
> correct behavior.  Again, the test suite's expectation is probably  
> wrong.
>
>
>> Bug in _all_docs: extra incorrect row returned when ?key= is  
>> specified
>> --------------------------------------------------------------------- 
>> -
>>
>>                 Key: COUCHDB-196
>>                 URL: https://issues.apache.org/jira/browse/ 
>> COUCHDB-196
>>             Project: CouchDB
>>          Issue Type: Bug
>>          Components: HTTP Interface
>>            Reporter: Jason Davies
>>         Attachments: collation_ids.diff, collation_test.2.diff,  
>> collation_test.diff, couch_db_updater.diff, view_coll.js
>>
>>
>> I first noticed this when attempting to reverse the order of docs  
>> displayed in Futon, when listing the design docs.  When the order  
>> is reversed, non-design docs are displayed.
>> After digging deeper I discovered that querying _all_docs with  
>> key="Z" can potentially return two rows, with keys "Z" and "a".
>> I will attach a test case to reproduce this.  My locale is set to  
>> en_GB.UTF-8, which could be related to this problem.
>
> -- 
> This message is automatically generated by JIRA.
> -
> You can reply to this email to add a comment to the issue online.
>


Mime
View raw message