[
https://issues.apache.org/jira/browse/COUCHDB-1125?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13020886#comment-13020886
]
Paul Joseph Davis commented on COUCHDB-1125:
--------------------------------------------
So I'm confused about what's going on here. Let me see if I can draw pretty
things.
Given keys:
1
2 # a
2
2
3 # b
4
5 # c
5
5 # d
6
I've noted four rows that we might be interested in in referencing.
So we have basically four ranges as far as I can tell. (a->c, a->d, b->c, b->d)
and the inclusive ends will determine the various ranges.
So AFAICT, inclusiveness means "include rows equal to the key". So by default,
we run inclusive_start, non_inclusive_end. inclusive_end then came around so
that we could include keys equal to the end key which means we don't have to
construct a key one greater than our range of interest.
IIUC, then what we're really trying to do is create a inclusive_end=false
option which is what's being proposed.
Is that in agreement with what everyone else is thinking?
Also, +1 randall's inclusive=start|end|both option.
> implement inclusive_start view option
> -------------------------------------
>
> Key: COUCHDB-1125
> URL: https://issues.apache.org/jira/browse/COUCHDB-1125
> Project: CouchDB
> Issue Type: Bug
> Affects Versions: 1.2
> Reporter: Jan Lehnardt
> Priority: Minor
> Attachments: inclusive_start.patch
>
>
> From COUCHDB-194:
> I suggest to generalize to left or/and right opened range.
> Because, to select a left opened range of keys, we have to use a tip.
> Exemple :
> keys = [1, 2, 3, 4, 5]
> to select where 2<key
> We have to do : startkey=2&skip=1
> But :
> If keys are no unique, the "skip" tip no more works.
> Ex: keys = [1, 2, 2, 3, 4, 5]
> The request startkey=2&skip=1 doesn't work because a "2" key is returned.
> (ps: non unique keys can be a wanted result)
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
