Naming: mapping.Document conflicts with client.Document

[GoogleCodeExporter]

Could we rename 

    mapping.Document

to

    mapping.DocumentMap

to better avoid the naming confusion?

In addition, the documentation at
http://packages.python.org/CouchDB/mapping.html

says (mine emphasised)

    To define a document mapping, you declare a Python class inherited from **Document**, and add any number of Field attributes:

Please change that to

    To define a document mapping, you declare a Python class inherited from **mapping.DocumentMap**, and add any number of Field attributes:

This will probably break a lot of things, and is a breaking change, but would 
be nice to see.

Original issue reported on code.google.com by SpaX...@gmail.com on 7 Sep 2011 at 3:56

[GoogleCodeExporter]

I don't really think the name should be changed. However, IMO, the 
documentation is not really helpful in this regards. There should be a topic on 
What's the difference between couchdb.client.Document and 
couchdb.mapping.Document.

This a rather confusing thing at first. Since we may expect some unique 
interface to Documents. However, this is a feature I really appreciate: 
mappings are designed to cover specific use cases; and not all possible uses 
cases. So, having a simple/direct interface to CouchDB json documents as dicts 
is really useful thing.

Best regards,
Manuel.

Original comment by mva.led@gmail.com on 7 Sep 2011 at 12:42

[GoogleCodeExporter]

Thanks Manuel.  Even if it's a documentation update, I would greatly appreciate 
it, as I lost an hour today trying to figure out why my Document (from couchdb 
import Document, who knew?) didn't inherit from the right methods, and I saw 
iterkeys()...

Original comment by SpaX...@gmail.com on 7 Sep 2011 at 12:57

[GoogleCodeExporter]

I suppose explicit Document import in documentation have to solve this 
misunderstood.

Original comment by kxepal on 11 Oct 2012 at 11:58

• Changed state: Accepted
• Added labels: Component-Docs, Milestone-0.9

Attachments:

• couchdb-python-198-r1.patch

[GoogleCodeExporter]

I've pushed your patch as revision 911a7e72d8a3, thanks. I think we can 
consider this issue fixed!

Original comment by djc.ochtman on 12 Oct 2012 at 8:20

• Changed state: Fixed