The document “docId” does exist, the cas value matches the stored document (I obtained it separately via N1QL), the bucket used is an instance of CouchbaseBucket.
When I use
bucket.get(“docId”)
beforehand I get cas 1452605940454916096.
After replacing the document content via Java SDK the CAS value is still different:
Java SDK
1452689801718661120
N1QL
1452689801718661000
Maybe it’s a feature I haven’t read about in the documentation yet, but it seems a little odd. Thanks in advance for any answer.
that doesn’t make sense to me. How can the CAS match the stored document if it does not exist?
Every time you replace a document, the CAS value is changed. Can you send over a piece of code that doesn’t do what you expect it to do? I bet its just a simple understanding issue.
No change to the document between the Java get and the N1QL select, just using two different ways to obtain the CAS at the same time.
As I mentioned in my first post, the CAS values look similar, just last two or three digits are different.
I tried N1QL via REST, Query Workbench and Java SDK (bucket.query(N1qlQuery)) with the same result - the CAS is different from the one obtained via Java SDK (bucket.get(String)).
Yes, I agree, according Couchbase concepts the CAS doesn’t have any parts, it has to be equal as a whole number.
What I was trying to suggest is that if the CAS value differs just slightly (last digits) when obtained by Java SDK vs N1QL. This maybe points to a small rounding/encoding/transformation bug. You know best how the CAS is stored/calculated internally and also how is it propagated to the outside world
I’ve put together a small maven project which shows the discrepancy, just run com.couchbase.test.cas.Main.main.
It’s using the newest 2.2.3 Java SDK but the behavior was the same on 2.2.2. Couchbase is running locally on my Windows 7 64bit, server version 4.1.0-5005 Enterprise Edition (build-5005), it uses a TEST bucket with a primary index, JDK version 1.8.0_51.
Couldn’t download your attachment…
Here is what I tried:
public class CasN1qlVsGet {
public static void main(String[] args) {
Cluster cluster = CouchbaseCluster.create();
Bucket bucket = cluster.openBucket();
try { bucket.remove("testCas"); } catch (Exception e) {}
long initialCas = bucket.insert(JsonDocument.create("testCas")).cas();
long updatedCas = bucket.replace(JsonDocument.create("testCas", JsonObject.create().put("value", "mutated"))).cas();
N1qlQuery casQuery1 = N1qlQuery.simple("SELECT META(default).cas AS cas FROM default WHERE META(default).id = \"testCas\"");
N1qlQuery casQuery2 = N1qlQuery.simple("SELECT META(default).cas AS cas FROM default USE KEYS \"testCas\"");
long n1qlCasWhere = exec(bucket, casQuery1);
long n1qlCasUseKeys = exec(bucket, casQuery2);
long getCas = bucket.get("testCas").cas();
System.out.println("CREATION : " + initialCas);
System.out.println("UPDATE : " + updatedCas);
System.out.println("N1QL WHERE : " + n1qlCasWhere);
System.out.println("N1QL USE KEYS: " + n1qlCasUseKeys);
System.out.println("GET : " + getCas);
}
private static long exec(Bucket bucket, N1qlQuery query) {
N1qlQueryResult result = bucket.query(query);
if (!result.finalSuccess()) {
System.err.println(result.errors());
return -1L;
}
if (result.allRows().isEmpty()) {
System.err.println("Empty rows");
return -2L;
}
return result.allRows().get(0).value().getLong("cas");
}
}
This outputs:
CREATION : 328484819173376
UPDATE : 328484827496448
N1QL WHERE : 328484827496448
N1QL USE KEYS: 328484827496448
GET : 328484827496448
Note that if no primary index exist, WHERE flavor will fail whereas USE KEYS flavor will still perform:
[{"msg":"No primary index on keyspace default. Use CREATE PRIMARY INDEX to create one.","code":4000}]
CREATION : 328383548882944
UPDATE : 328383558451200
N1QL WHERE : -1
N1QL USE KEYS: 328383558451200
GET : 328383558451200
Didn’t even use a particular scan consistency on the N1QL queries, and cas are the same.
Ran into it again, it seems whenever you create multiple buckets and N1 Query on it (the other buckets besides the default one), it will return an invalid CAS (at least on Mac OS X). I’ve experienced this problem now with 4.0 and 4.1. Any help on this would be appreciated.
