Design Question/Request: Why do .set() and .add() return OperationResult instead of ValueResult?


When I .get() something from the server I get a ValueResult object. It contains three key items that I will frequently need together: key, value and cas. When I do a .set() or .add(), the client library returns me an OperationResult that only has key and cas.

It would simplify my code if .add() and .set() returned on success a ValueResult with the value property set to the value we just sent to the server. Or, at least, return me a ValueResult object and let me put the value in the property. Otherwise I have to create a property only class or use a cumbersome dictionary. Neither of which are as nice as just being able to get the value out of the .add() or .set() result.

Thank you for considering this request.


1 Answer

« Back to question.

The Result objects and subclasses contain only the information received from the server wrapped up in a nice object. They are very lightweight objects implemented in pure C, and as such cannot contain extra fields.

For a set and add operation, we naturally don't receive the value we just stored from the server (as it's assumed the actual value is still present) and therefore it would be a performance hit to store the extra data. Consider if the value was particularly large, it would be a significant hit.

Furthermore, the Result object is created only after we receive the result from the server. For a set or add operation, the client at this stage does not keep track of the value in any form.

Would it not be simpler to just make your own application-level object (such as a namedtuple) to set the fields you need?