Sync Gateway Support

[CelsoSantos]

Hello,

How well does this work with the Sync Gateway? I see that you're "just" wrapping Couchbase SDK methods (very similar to Node-Ottoman) but it's not clear wether or not the Sync Gateway is supported.

Could you clarify please?

Best Regards,
Celso Santos

[fogine]

I don't have currently user-experience with using Couchbase Mobile solution.
The Couchbase-ODM is being developed with extensibility in mind so I don't see a problem with having specific features for Sync Gateway in the future.
However as far as I know the main behavior logic of the Sync Gateway is statically defined function provided in config file of Sync Gateway server. Currently, the Webhooks is only way I can think of in which you could shift processing logic to a nodejs server and take advantage of the ODM. This should be possible with current v1.0.0 release.

If you have specific feature ideas in mind or ideas about integration with the Couchbase Mobile, I'd like to hear about them!

[fogine]

To further clarify this question... currently the Couchbase-ODM does not implement the Sync Gateway's REST API which is currently the only supported way how to make CRUD operations on a bucket ( connected with a Sync Gateway server ) outside of the static Sync Gateway function provided in config file.
It's because Sync Gateway's revision manager keeps track on revisions' metadata of documents. In case you would try to modify documents with other access method than REST API (for example with couchbase-sdk), documents' metadata would get out of sync. Thus read operation is the only operation you can currently safely make with Couchbase-ODM on buckets connected to Sync Gateway.

I'll consider implementing Sync Gateway REST API to the Couchbase-ODM. I'm open to ideas/suggestions.

[fogine]

Note that Bucket Shadowing would solve mentioned issues for a price of having twice as large data.

[CelsoSantos]

Hello @fogine ,

I can confirm that it doesn't work with the sync gateway. Actually, ODM presents the same exact issue that Ottoman does: using underscore initiated values (e.g., _id and _type).

When you try to spin a new instance of the Sync Gateway and it starts to synchronise, the SG will display several error messages with the following content:

2016-08-07T18:57:22.332Z Shadow: Pulling "Brand_8bc27022-f0f8-4dde-98e2-80c22b0f199c", CAS=14689944eded0000 --> rev "1-18f57a9524bba13cdfbe669c069f89be"
2016-08-07T18:57:22.332Z WARNING: Error applying change from external bucket: 400 user defined top level properties beginning with '_' are not allowed in document body -- db.(*Shadower).readTapFeed() at shadower.go:81
2016-08-07T18:57:22.346Z Shadow: Pulling "UserBrand_aac32836-c6bd-4b81-9b9d-7022c7279b36", CAS=1468992b50350000 --> rev "1-8ca867ee37695f8970a67a8bf60385df"
2016-08-07T18:57:22.346Z WARNING: Error applying change from external bucket: 400 user defined top level properties beginning with '_' are not allowed in document body -- db.(*Shadower).readTapFeed() at shadower.go:81
2016-08-07T18:57:22.346Z Shadow: Doc "UserBrand_userId_brand_3367fec8-4f0f-47cc-bd01-5bec903eadf9_Potato" is not JSON; skipping
2016-08-07T18:57:22.346Z Shadow: Doc "[email protected]" is not JSON; skipping
2016-08-07T18:57:22.349Z Shadow: Pulling "User_3367fec8-4f0f-47cc-bd01-5bec903eadf9", CAS=1468992b52000000 --> rev "1-d0a02da949bf30ab8f033997eb6acf86"
2016-08-07T18:57:22.350Z WARNING: Error applying change from external bucket: 400 user defined top level properties beginning with '_' are not allowed in document body -- db.(*Shadower).readTapFeed() at shadower.go:81

My suggestion would be to change _id and _type to docId and docType (or doc_id and doc_type), respectively.
This way compatibility with the Sync Gateway would be ensured.

[fogine]

Hello @CelsoSantos,
this shouldn't be really a problem as these property names are just the defaults. Schema structure as well as documents' keys are fully configurable so it's possible to use the ODM with existing dataset without a need to migrate to different schema structure.

You can change internal property names with schemaSettings.doc.idPropertyName and schemaSettings.doc.typePropertyName options of the options object provided to either Model definition or overwrite defaults for all Model definitions when instantiating new CouchbaseODM object.

I also recommend you to go through available Tutorials so you get familiar with current possibilities of the ODM.

If there is anything unclear in the public API specification, please fill an issue or better - comment on the Diqus module under related documentation section so I can clarify further.