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

Gentlefolk,

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.

Anon,
Andrew

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?