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