I have documents with date property, and i need to query those by date range. the date is in the doc id, as well as in a property date. I have figured out two options:
USE KEYS ["audience:aud1:2016-01-01", "audience:aud1:2016-01-02", "audience:aud1:2016-01-03", "audience:aud1:2016-01-04"]
WHERE date BETWEEN '2016-01-01' AND '2016-01-03'
I tend to believe that option #1 is more efficient, because it uses the primary key index. of course I can create a secondary index on the field date but it would consume its resources.
However, in option #1 I must pass all dates in the range. if its a range of 30 dates, it means 30 values… instead of just begin/end date with BETWEEN clause.
Is there a way to benefit both worlds, and generate the USE KEYS clause dynamically, given begin/end dates of my range?
I don’t think its the right way to go, because it will only work within a month. if I need a range from the middle of one month to the next, it won’t work. For example, I need something smart enough to know when is the last day of the month, and know to advance the month after the last day (01-30, 01-31, and then go to February with 02-01).
Also, If i do string concatenation with your suggestion, i need to handle case when day value is one digit, and add padding zero before it… and things like that, which opens more room for mistakes (so “1” turns into “01”, but “15” is just “15”)
Is there a way to do dates range somehow?
or to do USE KEYS with greater than operator? something like "give me all documents of primary key greater than ‘2016-06-01’ similiar to what we can do with regular map-reduce views
So my suggestion to add that ability to USE KEYS still makes sense, if it’s
more efficient (is it?) and I guess the underlying index structure already support
it so it’s just a matter of implementing it
Again, this is a suggestion. I unserstand that TODAY we can only use it for discrete values…
If Couchbase would allow to use it with ranges as well as I suggested, it means users would not have to create a secondary GSI index just for that purpose, and save the costs of an index. I think my suggestion makes a lot of sense.