couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Groskopf (JIRA)" <j...@apache.org>
Subject [jira] Created: (COUCHDB-485) 'startkey_docid' should function like 'startkey'
Date Tue, 25 Aug 2009 18:23:59 GMT
'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.


Mime
View raw message