I am migrating an application from Bucket Shadowing to direct access of Sync Gateway data via the SG REST API, as recommended in github.com/couchbase/sync_gateway/wiki/Bucket-Shadowing.
Although, in andy’s contribution on Feb 25 in Cannot query view in sync gateway via user port, it’s stated otherwise, I suspect that, after deleting a document, subsequent view queries, done following http://developer.couchbase.com/documentation/mobile/1.2/develop/guides/sync-gateway/accessing-cb-views/creating-and-using-a-view/index.html, appear to work on a stale index that still contains the deleted document.
Unfortunately, there is no API reference for querying SG views via REST, apart from the sketch quoted above. That leaves me with the question: Is there any way, when querying a view in an SG bucket via REST, to set the stale parameter to false, so that I can be sure the view will deliver up-to-date results? I know there are performance issues with requiring stale = false, but inconsistent results aren’t an alternative.
As I understand it, views are not supported in the sync gateway. Its a feature you have to switch on, although I’ve never managed to get it to work. I was told if you do switch it on, then the
stale=false is the default setting, hence the indexing performance concerns. I think the short answer to your questions is no, and you may have to work around the problem.
I ended up creating a small application server that exposed a few indexes in my SG bucket. Or maybe you could just sync the data to your clients and create the view in couchbase lite?
thanks for your answer. The link you give is about querying views in SG via the user port. I don’t have this problem, as all my accesses are done via a server application sitting on the same server as CB, so I use the admin port.
I also read that stale=false is the default, but the thing doesn’t behave that way. If I delete a document and subsequently query the view and fetch the documents, I get a 404 error on the deleted document, indicating that it was still contained in the view.
My app is on the server as well as on the clients, so I need that REST logic on the server. As bucket shadowing is strongly discouraged, this is the only way to build an app on data that get synced to mobile devices.
I don’t think it’s correct that stale=false is the default value; I believe it’s stale=update_after. However, you can set stale=false as a query parameter on the Sync Gateway view call.
I agree that we need better documentation for the view API - I’ll look into that.
One caveat - this won’t necessarily solve your problem in all scenarios, as the write/delete operations being done through Sync Gateway don’t wait for the document to be indexed before returning. Your stale=false view query will ensure that the view gets refreshed with whatever has been indexed, but it won’t guarantee that the latest updates have been indexed.