We don’t currently have an Exists method in 2.0, however the 1.3.X implementation is really just Observe with ReplicateTo.Zero and PersistTo.Zero. Given that information you can get the same behavior in 2.0 by calling it’s equivalent Observe with those parameters.
Although Exists may never become part of the IBucket interface, it would be possible to add it as an extension method. You would simply do what I described above in it’s implementation.
@nick_adcock you will get a response indicating the item doesn’t exist if it isn’t there. As far as applications are concerned, it exists regardless of durability. That’s just additional information that you’d use if specifying Durability Requirements when changing data.
Of course, if there’s a failure and it’s not persisted or replicated, the change can be lost. That’s the reason the info is there. The client already has highlevel support for that though so just your low level check for existence can see if the observe command responds with the item existing or that it’s not known.
The problem I’m seeing is not an issue with checking for durability requirements per se but with using the method to check if a document exists as Jeff suggested.
All tests are done with no durability requirements (i.e. ReplicateTo.Zero and PersistTo.Zero)
If I call observe with an existing key and no CAS then I get get ObserveResponse.DurabilityNotSatisfied
If I call observe with an existing key and the CAS then I get get ObserveResponse.DurabilitySatisfied
If I call observe with an non-existing key and no CAS then I get get ObserveResponse.DurabilitySatisfied
Now if these are the expected responses then I can code this in (i.e. set CAS to 0 and if the return is NotSatisfied then the document exists, else it doesn’t) I would just like to confirm this is the case.
It does seem a tad odd though as I would you would not know the difference between a document that has matched the durability requirements and one that simple doesn’t exist.