In database I have more than 1000 records are there, if I am not providing any filter it’s returning 66 rows and if I provide filter it is only returning 2 records.
If I run the view on Couchbase Console, it is showing me all records.
Do I need to configure some thing to pull all rows from a view?
did you make sure to publish the view and then access the published one from both SDK and UI? Development views can vary greatly in the data they return, only a published view will give you the right output on your complete dataset.
as noted in the other forum post, it seems you are running on development views. Publish your view into production, then the data set will be accurately returned.
@vinod how do the keys look like you are emitting and how does the view query generated look like? You can run toString() on it to see the http query URI and compare them.
@vinod you are right though, the toString() method on ViewQuery doesn’t output the keys…
Since the keys is the only parameter that can be large enough to make a switch from GET to POST necessary, we didn’t include them in toString to not risk a too large string dump.
However, I think we can at least show a boolean flag in toString that says if the keys is set or not. I created JCBC-838 to track that.
Note that we don’t really keep the list around, but rather directly store is as a JSON string to pass it to the view engine as is, so we can’t conditionally dump it depending on its number of keys…
To more exhaustively dump a ViewQuery, you’d have to call both toString() and getKeys().
Having a very similar issue here… inclusiveEnd() seems to help, but I’m basically trying to delete every key that a view returns in a batched process.
I always get the correct value for totalRows(), but I am certainly not getting data back in a consistent manner.
Very often, the rows are empty when data is expected. Making the same query from the command line (taking what the debugger shows for the parameters), of course the data shows up…
I have tried using skip() to skip the # I’ve deleted and that seemed to help, but that does not reliably account for data that gets inserted while this operation is going on. I’ve also experimented with Stale.UPDATE_AFTER (expecting to not need to use skip), but again, odd behaviors.
I suspect that my issues are mainly around the fact that I’m doing deletions…
Using Stale.FALSE of course makes it all work properly. Certainly not ideal, however.