Partial results from view


I have a view that emits user’s names:


When I query for a specific name, e.g., name=“John” I get x results and some docs are missing.

When I modify the view to emit only docs with name=“John”:

if ("John) emit([]);

I get much more than x results.

View is in dev. “full_set=true” selected in UI. no limit.

What am I doing wrong ?

Can you post the code you’re using for the query with the SDK or the parameters you’re using in the UI? There’s a nice little URL you can click on in the UI and if you right click it, you can paste it here and we can see all the params.

This is the query:


I removed the limit and skip and replaced with John for the example.

if ("John) emit([]);

There are 27 results. Without the filtering condition there are 47 results.

I have a suspicion about what it may be. Can you make the endkey [“K”] and see if it works properly? I have a suspicion there may be a bug with inclusive_end, which I just observed recently but need to verify.

Also, note that you can request things that match a particular key with the “keys” argument. In this case, “John” alone. No need to have startkey/endkey be the same.

I’m using “keys” and not just “key” because the name is only part of a complex query with several ranges.

When I replace the end key with “Joho” (instead of “John”) it returns the full list.

What should I do ?

Can you remind me about ranges ? Should the fixed values by first and then the ranges or vice versa or it doesn’t matter ?


When the first key (first name) starts with “a” and ends with “zzzz” and the the second (family name) starts and ends with “smith” the result set is actually EVERYTHING.

Is there a way to filter only by family name (the second predicate) without creating a new view ?

There is no way to do so at the moment with views. The best method is to filter it at the client side at the moment. If you’re using the Java client, the RxJava interface makes this pretty straightforward.

N1QL (in 4.0 dev preview) will have more filtering options at the cluster side.

Filtering the entire database client side is obviously not a good solution
I’ll create a new view

Thanks for answering

I agree it’s not ideal, but if the query is likely to match many of the results it’s not always bad (this is sort of the selectivity on an index) and you can fetch the underlying documents after the filter, as the view is effectively the the index and the underlying documents are the result.

I understand the scenarios where it can be beneficial, but in my case I’m looking for only one user by his name