Verification of sync.gateway config

Hi

I’ve been experimenting a little with config of sync. gateway lately to obtain a smooth operation where the gateway automatically handles conflicts.

So I would appreciate if someone with more knowledge could just quickly glance over the settings and either confirm that they seem Ok - or suggest areas I need to revisit:

	"use_views":false,
	"num_index_replicas":0,
	"bucket": "data",
	"server": "http://db1,db2:8091",
	"username": "....",
	"password": "....",
	"enable_shared_bucket_access": true,
	"import_docs": true,
	"users": { "GUEST": { "disabled": true, "admin_channels": ["!"] } },
	"allow_conflicts": true,
	"revs_limit": 100

Obviously, I also have an import_filter and sync function to handle what is being sync’ed. I think those are behaving the way I want them now :slight_smile:

Is it correct that with the above settings I should not see any “Conflict messages” neither in sg_info.log nor on the console in the app? Other things I should look out for to ensure everything is working smoothly?

Thanks in advance!

I’m not sure what you mean by allowing Sync Gateway to automatically handle the conflicts. The snippet of config you provided will allow conflicts to be created, and your documents will become branched until those conflicts get resolved.

Automatic conflict resolution needs to be done on mobile devices before revisions are pushed to Sync Gateway.

Well, I have read the “conflicts are automatically resolved” in the documentation.

Prior to the above config I had "allow_conflicts"=false as that seemed to be the right choice when I first set up Sync.Gateway a while back. However, during testing and development I have seen messages about conflicts - typically after having updated some data on the server (in bulk) and subsequently started one of the devices for testing app functionality.

Ideally, these changes could be “merged” as I know from other replication technologies. However, I am also fine with newest edition wins.

I just re-visited the blog article you linked to and see that I may have been confused a little by the “…automatically resolved” and the default value for allow_conflicts". However, as I can see from the blog article the value of this parameter doesn’t matter when I only have CBLite 2+ clients…

So if I wanted to perhaps merge the contents of some documents (e.g. the ones “owned” by the user) I could register a conflict resolver on the replicator that would then kick in if a conflict was identified by the pull replication? Otherwise, I don’t have to do anything to just get the default conflict resolution?

Ah this does indeed simplify things for a 2.x only setup. In any case, I would recommend keeping allow_conflicts=false. You don’t want to accidentally be creating branched revtrees without having a process to manually resolve these conflcits on the SG side.

However, during testing and development I have seen messages about conflicts - typically after having updated some data on the server (in bulk) and subsequently started one of the devices for testing app functionality.

Figuring out what scenarios you see the messages about conflicts would be good to know, and a copy of log messages would be useful to determine exactly what you’re seeing. It could be the case that by setting allow_conflicfts=true to remove these messages is actually creating conflicts you’re not aware of.

So if I wanted to perhaps merge the contents of some documents (e.g. the ones “owned” by the user) I could register a conflict resolver on the replicator that would then kick in if a conflict was identified by the pull replication? Otherwise, I don’t have to do anything to just get the default conflict resolution?

This question is better suited for somebody from the Couchbase Lite team to answer, but that is my understanding, yes.

1 Like

Thanks for your replies.

Yes, I have reverted to "allow_conflicts"=false - as you pointed out that makes sense.

At the moment we have not gone live with the new app and the Sync.Gateway integration. And therefore, I sometimes have to fix “old” data with some updates to data that we now do in the application - and when this data replicates to the devices I can see why we get conflicts. However, I was afraid that these conflicts were not handled. But the blog article states that they are!

Not sure if I need to handle some replication conflicts myself… But I should be able too find some documentation about that if I want to go in that direction.

Thanks for getting back - so it turned out not to be a silly question :innocent: