Michael Salmon | 28 Mar 09:59 2013

Re: API design for new Python SDK

Here are some comments/goals (can't edit wiki). Grain of salt required, as I'm new at this db, but maybe that is a helpful perspective..

#1. Error messages should be more descriptive, and cascade server error-codes to user-code. For example if a 401 occurs today, here's what client.py does...

client.py:#59
requests.get(server_config_uri).json() # this code is not very friendly...

raceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "/usr/lib/python2.7/site-packages/couchbase/client.py", line 59, in __init__
    jsonResp = requests.get(server_config_uri)
  File "/usr/lib/python2.7/site-packages/requests/models.py", line 604, in json
    return json.loads(self.text or self.content)
  File "/usr/lib/python2.7/site-packages/simplejson/__init__.py", line 455, in loads
    return _default_decoder.decode(s)
  File "/usr/lib/python2.7/site-packages/simplejson/decoder.py", line 374, in decode
    obj, end = self.raw_decode(s)
  File "/usr/lib/python2.7/site-packages/simplejson/decoder.py", line 393, in raw_decode
    return self.scan_once(s, idx=_w(s, idx).end())
  File "/usr/lib/python2.7/site-packages/simplejson/scanner.py", line 119, in scan_once
    return _scan_once(string, idx)
  File "/usr/lib/python2.7/site-packages/simplejson/scanner.py", line 84, in _scan_once
    raise JSONDecodeError(errmsg, string, idx)
simplejson.scanner.JSONDecodeError: Expecting value: line 1 column 1 (char 0)

#2. Do not go back to the URI approach without a good reason. Because it's already flip-flopped from (a) to (b) http://www.couchbase.com/develop/python/next

#3 If getting rid of the bucket abstraction that's fine, then all calls get handled by a client object I imagine, and you pass in the bucket name to the db connection. It does imply though developers will need to keep extra database connection objects per bucket, vs before they could keep fewer db connections and query for the bucket when needed. Though I'm assuming cost of instantiating the connection is much higher than the bucket, at least that's what the docs indicate

#4 Avoid using different terms for the same thing, e.g. "key" and "documentID". docID makes more sense to me and is in the web GUI. key is in all the api documentation today though.

#5 bonus points - implement updating a field within a doc, I believe there's a feature request in jira: e.g.
doc = client.get("docID") # or bucket.get depending if that's still around
doc.replace("{'some': 123}") # doing the replace on the doc itself, instead of through the client. but either is fine

Thanks,
Michael




On Mon, Mar 25, 2013 at 1:34 PM, Volker Mische <volker.mische <at> gmail.com> wrote:
Hi all,

it's time to start thinking about the API for the new Python SDK. This
time I've put some bits in the Couchbase wiki to get discussion started [1].

After my little research I've the feeling that the Ruby SDK got a lot of
things right and that it might make sense to have the Python SDK pretty
similar to it.

Though nothing is set in stone, so please keep the ideas coming.

[1] http://www.couchbase.com/wiki/display/couchbase/Proposed+Python+API

Cheers,
  Volker

--
You received this message because you are subscribed to the Google Groups "Couchbase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to couchbase+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org.
For more options, visit https://groups.google.com/groups/opt_out.



--
You received this message because you are subscribed to the Google Groups "Couchbase" group.
To unsubscribe from this group and stop receiving emails from it, send an email to couchbase+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit https://groups.google.com/groups/opt_out.
 
 

Gmane