My iOS app sets up continuous pull and push syncing/replication on startup, however when existing documents are updated on the “remote” Couchbase Server I expected this to trigger the app into pulling down the updated documents, but nothing happens. I notice if I switch out of the app (e.g. by returning to the Home screen) and then switch back to it, my sync-progress method runs, but there is no sync activity. What am I doing wrong?
Using:
Couchbase Server Community Edition 3.0.1 locally on OS X 10.10 (Yosemite)
Couchbase Lite Community Edition 1.0.3.1
I built Sync Gateway from the sync_gateway repository on GitHub.
(a) You’re writing into the gateway’s bucket using Couchbase Server APIs directly without the gateway’s knowledge; don’t do that. Only use the Sync Gateway REST API (or replication from another client).
(b) The documents added to the gateway’s database aren’t assigned to any channels that your client has access to. Check the content of the documents, the sync function, and then user account that the pulling client is authenticating as.
I am updating the Couchbase Server directly using the Couchbase Java SDK 2.
While I am still developing my app the Sync Gateway is configured to sync documents across all channels and allow guest users to connect.
{
“databases”:{
“mybucket”:{
“server”:“http://localhost:8091”,
“bucket”:“mybucket”,
“users”:{
“GUEST”:{
“disabled”:false,
“admin_channels”:[“*”]
}
…
What I take away from your and borrrden’s replies is that replication between Couchbase Servers is different than replication between a Couchbase Server and (a client running) Couchbase Lite.
Am I right in thinking I can’t somehow simply direct my existing Java client to connect via the Sync Gateway, rather I need to use the Sync Gateway’s REST API?
Note:Do not add, modify or remove data in the bucket using Couchbase APIs or the admin UI, or you will confuse Sync Gateway. To modify documents, we recommend you use the Sync Gateway’s REST API. If you need to operate on the bucket using Couchbase Server APIs, use the Bucket Shadowing feature to create a separate bucket you can modify, which the Sync Gateway will “shadow” with its own bucket.
You wrote:
replication between Couchbase Servers is different than replication between a Couchbase Server and (a client running) Couchbase Lite.
You mean like XDCR? That isn’t compatible with Sync Gateway. XDCR is a simpler form of replication that can’t handle conflicts — basically you can only use XDCR if one side of the replication is a read-only mirror, or at least if you’re 100% sure the same docs will not change on both sides. Also, XDCR will write directly to the bucket bypassing Sync Gateway.
OK. From the documentation, for a new app like mine, the advise is to use the Sync Gateway REST APIs and utilise the Changes Worker Pattern.
That’s fine, but am I right in thinking there is no means to query MapReduce views through the Sync Gateway REST API?
With the Java client I was developing I intended to use MapReduce views stored on the Couchbase Server to perform stats on the documents - calculate mean, standard deviation and exclude outliers. I could use the REST API in conjunction with channels to identify the documents (I think), but the client would then have to filter documents (potentially) and perform the calculations. Wouldn’t it be more efficient for Couchbase Server to do this work rather than the client?
No not XDCR, I was thinking of the replication that happens between nodes in a Couchbase cluster.
Lastly, am I right to think that the “bucket shadowing” is more complex than using the Sync Gateway REST API and Changes Worker Pattern? Thanks Jens for your help.
It does, as of 1.0.3, but it looks like this hasn’t been documented yet. The API is the same as Couchbase Server and CouchDB — POST to /$db/$designdoc/_view/$view, on the admin port.
No not XDCR, I was thinking of the replication that happens between nodes in a Couchbase cluster.
Oh, I see. That’s kind of a different meaning of the word ‘replication’ — the nodes in a cluster do copy data to each other but only for failover purposes, and it’s invisible to the client. It’s not related to what the Sync Gateway does.
Not that it matters in my case, but I am curious why this is only available on the admin port? I realise Couchbase just released new SDKs, but do they have any future plans to enhance the SDKs to work with Sync Gateway?
Thanks for the clarification. I always thought one of the key selling points of CouchDB was its ability to define multiple masters and replicate between them, did this not carry over into Couchbase or are multiple masters simply a cluster? …I think I need to go away and read some more.
Because it just returns the results straight from Couchbase Server’s view engine, which ignores document ACLs. I have a branch of the Gateway that adds client support for queries, by interposing a filter that strips out results that come from docs the user doesn’t have access to, but it’s not been tested thoroughly yet.
I realise Couchbase just released new SDKs, but do they have any future plans to enhance the SDKs to work with Sync Gateway?
Good question; I don’t work on the SDKs, so you could try asking in those forums. The Gateway API is 90% identical to the CouchDB REST API, and there are CouchDB client libraries for most languages already.
I always thought one of the key selling points of CouchDB was its ability to define multiple masters and replicate between them, did this not carry over into Couchbase
The latter. The parts of CouchDB that were integrated into Couchbase Server 2 were the append-only B-tree storage format and the map/reduce view engine. The rest was stripped out, mostly because it wasn’t fast enough to keep up with the crazy speed at which Membase can create documents. So features like document revision histories and replication went away.
The intra-cluster communication in Couchbase Server comes straight out of the original memcached, with a lot of enhancements. Cross-data-center replication (XDCR) is a different protocol, but since docs have no revision histories it can’t work anything like CouchDB replication.
You can think of the Sync Gateway as adding CouchDB features back onto Couchbase Server. But it’s not fully integrated yet, so stuff like revision histories is added as ‘invisible’ data spliced into documents.
Hi all, I’ve got a question related to this. I realize that you should not make any changes on the sync server, but how about Couchbase console? I loaded up the to-do lite app, made a few entries and saw those appear in Couchbase via the console. I made some changes in the app and saw that it sync’d to the backend. However, when I performed an update statement within Couchbase console (via Query tab), it would not sync to the app on the device.
I’m learning about Couchbase and what I want to do is load up a bunch of reference documents on the backend (however easiest to do) and have those sync down to the mobile database and populate a pick list (picker view in iOS) of some sort.
Actually, I think that makes sense now that I think about it. Maybe there’s a tool out there that allows someone to do that from a more visual UI. Will have to look around.
I am using couchbase mobile for an app (Couchbase server 4.1.1, sync gateway 1.5.1, couchbase lite ios 1.3.1). I need to initiate an update for one particular field in one document on server side and let it automatically replicated to client side. Since it was suggested to use Sync Gateway API to do this in this thread, I tried, using the curl command generated by section " PUT[/{db}/{doc}] Create or update document" at this link:
it gave me error saying document already exist on the terminal, I deleted that document through the couchbase server console, the updated document(which is essentially recreated document after deletion) showed up on server console and reflect the change in that field, but the change is never replicated to the client mobile device(although the client is doing continuous pull replication). Can someone tell me what’s the right way to do this? Since I only need to modify one field in the document, is there any quick and easy way to do this? Using a curl command with dozens of lines just to modify one field doesn’t seem to be the best way.
To PUT an update of a doc, the body of the request has to include a _rev property with the current revision ID. That’s to ensure you don’t stomp on a later revision that was made after you GET the contents.
Modifying a document through the Couchbase SDKs without going through Sync Gateway isn’t allowed, prior to Sync Gateway 2.0 and Server 5(?) — SG doesn’t know about the change and its metadata gets out of sync.
The easiest thing is to GET the doc and redirect to a file; edit the file to change the property, then PUT the contents of the file. This works because the GET result includes the _rev property that the PUT expects. (Abut it can still fail if someone updates the document in between your GET and PUT; if so, retry from the start.)
