[MB-4781] start_key_docid returns unexpected (or unintuitive) results Created: 07/Feb/12  Updated: 09/Jan/13  Due: 07/Feb/12  Resolved: 17/Feb/12

Status: Closed
Project: Couchbase Server
Component/s: ns_server
Affects Version/s: 2.0-developer-preview-4
Fix Version/s: 2.0-developer-preview-4
Security Level: Public

Type: Bug Priority: Blocker
Reporter: Tommie McAfee Assignee: Benjamin Young
Resolution: Fixed Votes: 0
Labels: 2.0-dev-preview-4-release-notes
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment: 6 node cluster .deb build 653

Attachments: Zip Archive     Zip Archive     Zip Archive     Zip Archive     Zip Archive     Zip Archive     File query_with_key     File query_with_key_and_startkeydocid    

Below are the results from a query that returns multiple rows for a single key. The third document has id "0-8fbe114" but if I apply the start_key_docid filter I still get the same exact results with the list starting at doc id "0-14479a7." although the view should've returned a subset. I also tried start_key_docid in combination with start_key and end_key but neither of these returns a subset starting at the requested docid.

QUERY WITH KEY = [2008,11,1]
curl "" > query_with_key


QUERY WITH KEY = [2008,11,1] and START_KEY_DOCID = "0-8fbe114"
curl "" > query_with_startkeydocid

   ....results are the same as previous query, although I expected them to start with the requested doc_id...

Also noticed that "id" and "_id" are mismatch - not sure if that has something to do with the behavior of this filter.

Comment by Filipe Manana [ 07/Feb/12 ]
"start_key_doc_id" (same as startkey_docid) is meant to be used together with "start_key" (same as startkey), not "key".

The _id is because you're apparently emitting the documents themselves as map values. This is how it works in the Couch since ever, general rule: meta information in docs has a _ prefix, everywhere else (views, changes feed) it doesn't.
Comment by Tommie McAfee [ 07/Feb/12 ]
Right, I was advised to try with start_key, but results are the same...and are not starting at requested id.

Perhaps only the filters that can be used in conjunction with say "key" should be selectable in the UI. Otherwise a non-couch user may be expecting these filters to do something.
Comment by Filipe Manana [ 07/Feb/12 ]
Tommie, you specified "start_key_docid" - this doesn't exist - use "startkey_docid" or "start_key_doc_id".

Originally, in couch every name uses the _ logic to separate words - all except startkey, endkey and startkey_docid and endkey_docid. For these 4, the aliases "start_key", "end_key", "start_key_doc_id" and "end_key_doc_id" were added upstream (I did it) and to our codebase.

Comment by Tommie McAfee [ 07/Feb/12 ]
UI bug there in variable naming as this "start_key_docid" was added to query via couchbase 2.0 UI.

Also, I tried using startkey_docid and "start_key_doc_id" , but neither seem to be filtering the results.

Comment by Filipe Manana [ 07/Feb/12 ]
Tommie, do you think you can write a simple script to create that dataset and do the 2 queries?
I would like to try it locally.
Comment by Farshid Ghods (Inactive) [ 08/Feb/12 ]

can you please provide a test case which Filipe can run against cluster_run with one node ?
Comment by Filipe Manana (Inactive) [ 09/Feb/12 ]
Waiting for the testrunner test or a standalone script to reproduce.
Comment by Tommie McAfee [ 09/Feb/12 ]
Filipe, maybe you also have some data to give this a quick try.
  I tried it on a simple set of integers from data loaded in test runner and doesn't look like its working (startkey_docid = 684a59d-480)


also tried start_key_doc_id and start_key_docid
Comment by Farshid Ghods (Inactive) [ 09/Feb/12 ]
i also noticed that debug=true does not return any extra info .

Comment by Tommie McAfee [ 14/Feb/12 ]
Hi Filipe,

Still not getting the start_key_docid filter to work as expected. There is now a test in testrunner that you can use to reproduce this:

python testrunner -i <resource_file> -t viewquerytests.ViewQueryTests.test_simple_dataset_startkey_endkey_docid_queries

2012-02-13 19:41:14,686 - root - INFO - Quering view dev_test_view-11f6a22 with params: {'debug': 'true', 'start_key': 5000, 'startkey_docid': '"11f6a22-5100"'}
2012-02-13 19:41:14,687 - root - INFO - Params {'debug': 'true', 'start_key': 5000, 'connection_timeout': 60000, 'startkey_docid': '"11f6a22-5100"', 'full_set': True}
2012-02-13 19:41:14,687 - root - INFO - index query url:"11f6a22-5100"&full_set=true
2012-02-13 19:41:14,906 - root - INFO - view returned in 0.21882891655 seconds
2012-02-13 19:41:14,906 - root - INFO - was able to get view results after trying 1 times
2012-02-13 19:41:14,917 - root - INFO - key_set has 5000 elements
2012-02-13 19:41:14,917 - root - INFO - retrieved 5000 keys expected: 4900
Comment by Tommie McAfee [ 16/Feb/12 ]

I have this query result from using start_key = 20:


attempting to set start_key_docid to "da9d0f6-20" returns the same number of rows, but the first duplicate key should be skipped:

Comment by Tommie McAfee [ 16/Feb/12 ]
This is basically a bug with UI because it uses start_key_docid instead of 'startkey_docid'

this query works -
Comment by Benjamin Young [ 17/Feb/12 ]
Yeah, looks like it could have also been start_key_doc_id (per Filipe's first comment).

Will fix.
Comment by Benjamin Young [ 17/Feb/12 ]
Resolved: http://review.couchbase.org/13336

Feel free to close this ticket (or re-open it) based on the final review/merging.
Comment by Thuan Nguyen [ 17/Feb/12 ]
Integrated in github-ns-server-2-0 #303 (See [http://qa.hq.northscale.net/job/github-ns-server-2-0/303/])
    removing underscores from startkey/endkey fields. MB-4781 (Revision 9bc2bde6f88d43b273f7278e18a91c3871404cf2)

     Result = SUCCESS
Aliaksey Kandratsenka :
Files :
* priv/public/index.html
Comment by francares [ 28/Mar/12 ]
Does anyone know if this bug was fixed in DP4?
I´m using Couchbase version: 2.0.0 community edition (build-724) and still happens. I´m using startkey_docid and startkey query params.
Comment by Tommie McAfee [ 28/Mar/12 ]
Yes, this was fixed in dp4. What do you're id's and keys look like?
Depending on your docids, you should not have quote's around the startkey_docid, even if the id's are strings.
Comment by francares [ 28/Mar/12 ]
They are GUIDs.

When I call to the view with following URLs:


It returns keys like 03057CA7-5F27-4364-87FD-892548D8CB43, so the filter is not performed in the view.
Comment by francares [ 28/Mar/12 ]
Same happens with string type keys.
Comment by Tommie McAfee [ 29/Mar/12 ]
Well, couple of things here, as I also thought this was unintuitive before understanding how this used to work in couchdb.

Using startkey_docid requires 2 things:
1 that the startkey filter is also used in the same query
2 that the results returned from using startkey contain duplicate keys

so if I have:
   "key0" : "val0"
   "key1" : "val1" <_id = k1v1>
   "key1" : "val2" <_id = k1v2>
   "key1" : "val3" <_id = k1v3>
   "key2" : "val4"

I can do something like
starkey = key1, startkey_doid = k1v2

and my results would be
   "key1" : "val2" <_id = k1v2>
   "key1" : "val3" <_id = k1v3>
   "key2" : "val4"

Could be in your case the only thing you need is startkey if all your map functions are emitting unique keys.
Generated at Wed Nov 26 12:41:16 CST 2014 using JIRA 5.2.4#845-sha1:c9f4cc41abe72fb236945343a1f485c2c844dac9.