Different CAS value for the same document obtained via Java SDK and N1QL

Has there been any resolution on this issue?

Hi @geoffrey.mitchell,

It seems there were a few issues on this thread. There is still a rounding issue, because N1QL handles JSON numbers as 64-bit floats, which can lead to rounding errors at the margins.

In the thread, it seems there was another issue with Mac OS that went away.

It is the rounding issue that appears to be biting us. It is currently blocking our conversion to couchbase. There has not been any word on a fix for it?

We will fix it in N1QL. For now, can you perform your updates using the key-value APIs in the SDKs? That would unblock you while we fix this.

We are using spring-data-couchbase to integrate into our Java/Spring application. In order to work around this issue, I believe that we would have to re-fetch any object retrieved via a query using a get by ID before persisting it anywhere we are using optimistic locking (which relies on the CAS). We looked at that option and are not comfortable with the amount of extra code we would have to introduce to make it work.

Ok. We are giving this priority. JIRA ticket: https://issues.couchbase.com/browse/MB-20164

1 Like

That’s exactly the approach we are using as a workaround. We try to use covering indexes as much as possible to fetch just document keys and use them via the key-value API to fetch the full document with the correct CAS. Looking forward to the fix!

Thanks, @geraldss. Much appreciated.

1 Like

maybe it’s reasonable to add 4.1.X as “fix version” for https://issues.couchbase.com/browse/MB-20164 too?

Hi @egrep,

We will keep that in mind. It’s an extensive change (because numbers flow everywhere in the query engine), so we cannot promise.