WriteCas doesn't return new CAS value

[tleyden]

WriteCas only returns an error, but it should be returning an (err, newCas) pair.

In comparison, gocb's Insert method returns a Cas value.

In order to work around this, Sync Gateway currently needs to the following kludgy workaround:

bucket.Bucket.WriteCas(k, flags, exp, cas, v, couchbase.WriteOptions(opt))
observeResult, err := bucket.Bucket.Observe(k)
LogTo("DIndex+", "WriteCas: post-write cas value is %d", observeResult.Cas)
return observeResult.Cas, err

From an "Api neatness" standpoint, it would be preferable to modify the existing method rather than add a whole new method, even if it breaks some existing users when they try to point to the latest commit on the master branch. (they'd get a compile time error)

[tleyden]

@maniktaneja ping -- any thoughts on this?

[maniktaneja]

@tleyden Agree that the WriteCas should return the new cas value along with the error code. However, I am not sure how many other projects are using go-couchbase and there is way too much coordination involved to get them to change their code in lock-step fashion in order to not break the build. I will add a new API and put a comment deprecating the old one. Does that work ?

[tleyden]

It works, but doesn't feel ideal. The public API will become messier and harder to use.

I think most projects are pointing to a specific commit anyway, and so if and when they do point to a later they would expect some potential compilation errors. In this case, all they would need to do is to add , _ to their code in a few usage places.

@ceejatec do you happen to know the list of projects/modules depending on go-couchbase? Also, any thoughts on the breaking API changes comments above?

[maniktaneja]

@tleyden As far as i know most of the projects that use go-couchbase are pointing to the master so If I make changes to the public API I will end up breaking the build. It's only the manifest for a particular release, e.g. sherlock that are pointing to a specific commits.