Details
-
Bug
-
Resolution: Fixed
-
Major
-
None
-
None
-
None
-
1
-
SDK1: GA and Priority List, SDK9: Coll/Txn/Doc chipping, SDK11: Coll/Txn/Docs More Chip, SDK13: Coll/Txn/Docs More Chip
Description
Ideally, a developer would not have to remember what the various options are for a given operation, and they would all be represented explicitly in the Options objects themselves.
For instance, in Java, the GetOptions has an explicit withExpiry, project, and is derived from a CommonOptions object which contains timeout, retryStrategy, etc... So - when developing in java, this is all discoverable (unless you use Vi like I sometimes do), and is a great help.
In Python, GetOptions has an explicit timeout and project, and derives from OptionBlock. But OptionBlock has no common options, it is just a dict. Ideally, we'd pop some common ones (like timeout, retryStrategy) in there, and if OptionBlock does not extend a dict then if you use a clever IDE it will show all the options and none of the dict methods.
So - for sure we seem to need some things added (I just looked at GetOptions but we should sweep through all of them). For GetOptions, we need to support returning expiry, and specifying a retryStrategy, and perhaps other things but for sure that. Some of this may be handled by the explicit named parameters call to get, but it isn't part of the GetOptions explicitly. My concern above was just to make using it easier, by getting away from an underlying dict. That is of course worth debate.
A second thought/issue:
I'd expect the kv interface to work something like this:
opt = GetOptions().timeout(Seconds(3)) # we reuse this throughout the code perhaps |
...
|
collection.get('key', opt, expiry=True) #use the GetOptions passed in, but add in the expiry (just for this call) |
Now, calling it with the key and options does work, but I think the idea of the Options is that you'd reuse it, and sometimes tweak that slightly by adding something for specific calls (say, adding a cas() sometimes when mutating, or bumping a timeout or retry strategy, etc...). Right now, if I do this:
collection.get('key', opt, project=['someField'] |
I end up seeing an exception
couchbase_core.exceptions.ArgumentError: <Bad/insufficient arguments provided, inner_cause='ttl' is an invalid keyword argument for this function, C Source=(src/get.c,459)> |
So perhaps we don't quite handle this case yet... Worth some discussion.