couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Chris Anderson (JIRA)" <>
Subject [jira] Commented: (COUCHDB-485) 'startkey_docid' should function like 'startkey'
Date Thu, 27 Aug 2009 17:56:01 GMT


Chris Anderson commented on COUCHDB-485:

this patch should be not that hard, and I don't see it breaking anything either. It'd be an
ideal patch for someone new to the codebase to dig into.

> 'startkey_docid' should function like 'startkey'
> ------------------------------------------------
>                 Key: COUCHDB-485
>                 URL:
>             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.

View raw message