[jira] Resolved: (COUCHDB-485) 'startkey_docid' should function like 'startkey'

["Paul Joseph Davis (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/COUCHDB-485?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Paul Joseph Davis resolved COUCHDB-485.
---------------------------------------

    Resolution: Won't Fix

startkey_docid and endkey_docid are there to discern between identical keys from the same document.

> 'startkey_docid' should function like 'startkey'
> ------------------------------------------------
>
>                 Key: COUCHDB-485
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-485
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: HTTP Interface
>    Affects Versions: 0.10
>         Environment: N/A
>            Reporter: Christopher Groskopf
>            Priority: Minor
>
> The 'startkey_docid' and 'endkey_docid' parameters provide a way of sub-selecting rows for pagination when a view emits many rows with identical key values.  However, it seems both confusing and unintentionally limiting that 'startkey_docid' does not function the same as 'startkey' with regard to how included documents are identified.
> By this I mean, that if a a group of data is emitted with ISO 8601 timestamps as keys (e.g. "2009-08-25T12:00:00Z") then its possible to specify 'startkey="2009-08"' and include that example data, because it is collated after 'startkey'.  However, it those timestamps were emitted as doc ids instead of keys, 'startkey_docid'  will only act to filter the data if it _exactly_ matches a doc id.  Specifying 'startkey_docid="2009-08"' would not filter the data at all, even if every selected row has the same key.
> The benefit of implementing this change is that views which emit many identical keys could be sub-filtered based on document id.  In the case of my application, the first portion of a document's id is a timestamp, so I would be able to select a chronological subset of rows after they had been filtered by key.  Another possible use case is where doc ids are slugs--this would make it possible to select an alphabetical range after specifying a category as a key parameter.
> I haven't looked under the hood and I have never written Erlang, so I have no way of accurately estimating how significant this change would be.  Unless I'm misunderstanding something, this change should not break existing code.
> Looking forward to reading any feedback/comments/alternatives.
> Thanks,
> Chris

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.