incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Eli Stevens (Gmail)" <>
Subject Re: [ANN] couchable 0.0.1b1 (Python object to couchdb document mapper)
Date Fri, 13 Aug 2010 08:54:12 GMT
Hello!  :)

I agree that there are a number of similarities, and certainly
wouldn't have a problem with consolidating effort.  However, I've got
a number of use cases that seem to run directly counter to how both
couchdb.mapping and couchdbkit have been structured.  I certainly
wouldn't want to try and dictate how those projects should evolve,
just because my use cases are different!

>From what I could tell from the couchdb.mapping and couchdbkit
documentation (I will admit to basing this solely on the docs; if
there's more to these packages than I realize, I'd love to find out
more), I see three main points of differentiation for couchable:

- No requirement to inherit from a fixed Document base class.  This is
helpful if 3rd party objects need to be stored in CouchDB.
- No requirement to specify the schema in advance.  couchdbkit has
dynamic properties; I couldn't tell what would happen to unspecified
fields in couchdb.mapping.
- Can roundtrip data through CouchDB that doesn't have a native JSON
representation (example: dicts with tuple keys, arbitrary

There are also a few minor features, like mapping certain types to
attachments, the ability for the end user to specify conversion
routines for types that don't work out of the box (ie. don't have a
__dict__), and the ability to save and load an interlinked object
hierarchy (a is a doc that has a ref to b, which is also a doc, etc.).

Philosophically, it feels like couchdb.mapping and couchdbkit are
trying to take CouchDB documents and expose them to Python.  Couchable
aims to go the other way - take arbitrary Python objects and store
them in CouchDB (a poorly-stated goal of couchable is that *any*
Python object should be able to round-trip cleanly).  This results in
objects like 'a' in the following being able to round-trip cleanly, at
the expense of a somewhat loud document in CouchDB:

>>> import couchable
>>> cdb=couchable.CouchableDb('example')
>>> class SimpleDoc(couchable.CouchableDoc):
...     def __init__(self, **kwargs):
...         for key, value in kwargs.items():
...             setattr(self, key, value)
>>> a = SimpleDoc(name='AAA')
>>> a.dict_ = {'foo':'FOO', 123:'bar', (45, 67):'baz'}

   "_id": "main__.SimpleDoc:2a208810-467f-4feb-a5bb-98d0beb1e5e7",
   "_rev": "7-4706c617a5f8900956c76ecb6f2e2daa",
   "couchable:": {
       "keys": {
           "couchable:key:tuple:(45, 67)": {
               "couchable:": {
                   "args": [[45, 67]],
                   "class": "tuple",
                   "module": "__builtin__",
                   "kwargs": {
       "class": "SimpleDoc",
       "module": "__main__"
   "dict_": {
       "couchable:key:tuple:(45, 67)": "baz",
       "foo": "FOO",
       "couchable:repr:int:123": "bar"
   "name": "AAA"

Again, if I've misunderstood the capabilities of either of these
projects, please don't hesitate to correct me!  :)  It's getting late
here, but I'll try and check back before work tomorrow.


On Fri, Aug 13, 2010 at 12:28 AM, Dirkjan Ochtman <> wrote:
> On Fri, Aug 13, 2010 at 09:20, Eli Stevens (Gmail) <> wrote:
>> Couchable is built on the Python CouchDB package:
>> But has no affiliation with that project.
> This looks a lot like couchdb.mapping that we provide in couchdb-python.
> So I wonder why this is different? We'd love to have you help out with
> improving couchdb.mapping if you feel stuff is missing from that!
> Cheers,
> Dirkjan

View raw message