Expected behaviour of ExecuteGet?
Reposting here from Couchbase 1.8 forum:
Using the .NET v1.1.6 client against Couchbase 1.8.1, I'm getting surprising results from the new ExecuteGet() method
var key = Guid.NewGuid().ToString(); var result = client.ExecuteGet(key); // Doesn't exists Console.WriteLine(result.Success); // false Console.WriteLine(result.Message); // Unable to locate node Console.WriteLine(result.Value); // null client.Store(StoreMode.Set, key, "blah"); // Adding it result = client.ExecuteGet(key); // Does exist Console.WriteLine(result.Success); // true Console.WriteLine(result.Message); // null Console.WriteLine(result.Value); // blah
Is this behaviour by design? It seems that it isn't possible to distinguish between a network failure and a key that doesn't currently exist. In the case of a non-existent key, my expectation would be that Success == true but Value == null.
UPDATE: I checked out the master branch of couchbase-dot-net client repo and I can see that the test
CouchbaseClientGetTests.When_Getting_Item_For_Invalid_Key_HasValue_Is_False_And_Result_Is_Not_Successful
is passing and correctly setting a status code of 1 (StatusCodeEnums.NotFound). This makes a lot more sense. The problem is I don't get this same behaviour for my client (v1.1.6). I also can't seem to be able to get the release11 branch of couchbase-dot-net to compile due to differences in the Enyim client.
OK, I got the release11 branch working against a binary Enyim reference. The test still passes, but the result.Message is now "Unable to locate node" and the Status code is null (as it is for my version). The reason the test passes is that the assertions are quite loose:
protected void GetAssertFail(IGetOperationResult result) { Assert.That(result.Success, Is.False, "Success was true"); Assert.That(result.Cas, Is.EqualTo(0), "Cas value was not 0"); Assert.That(result.StatusCode, Is.Null.Or.GreaterThan(0), "StatusCode not greater than 0"); Assert.That(result.HasValue, Is.False, "HasValue was true"); Assert.That(result.Value, Is.Null, "Value was not null"); }So it seems that this is something that is improved in the latest version of the client. Any plans to release another 1.1.* version soon?