I don't know if I understand collated views right (and N1QL would be am option?)

Hi everybody…I’m not pretty sure if I understand well collated views, I only could found a couple of articles about it…I was trying this in the last night…my idea: create documents which are related to messages, every essage has an author and could have many destinataries (which are saved as an array)


“type”: “direct_message”,
“message”: “hello darling”,
“from”: “mark”,
“to”: [

now…my view is this

this works pretty fine…I get

1 null
1 null

now…I whish explore all messages posted by “mark”

I use startkey [“mark”,“a”,1]

endke [“mark”,“Z”,99999999]

the key for the meta.id is very ugly…I use 99999 but I suppose than would be a better way…however works good, the Z in the endkey also works as expected (“to” only use lowcase so Z is a good limit) now I would prefer than couchbase had something like redis where I can use * but is ok

the problem is when I which get all messages for a specific user…I tried this

startkey [“a”,“juana”,1]]
endke [“Z”,“juana”,99999999]

this return

3 null
1 null
1 null
1 null
2 null

is it ok?..I’m using collate views in a wrong way??

2 point: I was looking for n1ql and seems pretty nice, would be a good idea use
n1ql instead of views?..exist a performance penalty or any disadvantage about using
n1ql over views??..thanks!!.

Regarding (2) - it’s a great question, and we’ll soon have a whitepaper to guide what functionality each represents, and when it needs to be used.

At the moment, the key distinction is that Views are production ready and can be used on large data sets, but Query is in developer preview, which means that we don’t provide much performance guarantees. We also have several parts of Query Engine (such as secondary index) still in development. So we can’t yet compare Views and Query.

When Query does become production ready soon, the main distinction will be that OLTP like use cases will be covered by Query, and OLAP use cases will be covered by views. Please stay tuned for more on this!

Regarding the sort ordering question, let us consider the following example:

startkey [“a”,“juana”,1]
endkey [“Z”,“juana”,99999999]

If you have composite keys, it will follow the general idea of composite key based sorting. We do not support regular expression matching.

If you provide a startkey, endkey parameter for view query, it will respond with all keys greater than or equal to startkey and less than or equal to endkey.

The sort order evaluation is field by field. Say if there are two keys with same 1st field, then it will try to evaluate second field of the keys and see which one is lesser key. Again if the 2nd fields of the keys are equal, it will evaluate the third field and so on.

In the above example, view query will respond will all keys greater or equal to first field “a” and less or equal to second field “Z”. Since you do not have any keys with “a” or “Z” as first field, second and third fields are never evaluated for comparison. All of your keys fall between “a” and “Z” and hence all keys are returned.

thanks for the answer…but then how can I include results ommiting the first parameter?..I need ommit the first parameter which is the author, because only care the second parameter, is it possible using views?

thanks and sorry for the noob question

If I understand the question correctly, you need the first field ‘author’ only for sorting the entries. But in the end result you do not care about the first field. How do we omit the first field from the result ?

Since first field is a mandatory parameter for keeping the sort order correct, it is required in the mapped result. Since you need further filtering out results you should do it from your application that consumes the view query results.