Open GoogleCodeExporter opened 8 years ago
I feel a bit wrong conception.
The design module is using to define View functions and has ability to sync
their definitions with CouchDB, creating or updating design documents.
In this patch you adds _DesignDocument class which does not what everyone may
except.
The design documents for CouchDB are regular documents with special behaviour.
They have _id, _rev, _attachments, _conflicts etc. fields like any other docs.
They shares client.Document API and behaviour.
Additionally, the design documents may have special fields like views, shows,
validate_doc_update, rewrites and others which has special processing logic for
CouchDB side. These fields have to be defined with FunctionDefinition instances
or be some property-proxies to them.
Each FucntionDefinition acts as standalone design function which is bounded to
some design document. Passing multiple instances to sync_many _function_ groups
them and syncs with CouchDB. Having sync_many as _staticmethod_ of
DesignDocument class breaks all the conception since this method can not use
his own class to sync with database.
Take a look on issue-186 patch. There are only function definitions and
conception of fragile design documents preserved. It's very easy to wrap them
into DesignDocument class with nicer API to operate with them and sync with
CouchDB.
Original comment by kxepal
on 2 Sep 2013 at 6:25
kxepal, although _DesignDocument is a part of private API not public one (so
name is not so important), I agree it could cause misunderstanding. Now I
realize the better name would be something like _DesignDocumentDefinition. I.e.
a definition for the whole design document consisting of views, updates, shows
etc definitions.
I don't see a goal of working with design document thru the normal document
API. In my scenario, I need to define view, update, validate etc definitions
and then sync them in a bunch with DB. Then use some of them thru Database
class methods. That's all. Of course there could be a different usage
scenarios. Please, write your one.
Original comment by oliora
on 2 Sep 2013 at 7:51
BTW, I just love how many patches you turned this into! So much easier to
review. I hope we can all converge on a good design.
Original comment by djc.ochtman
on 2 Sep 2013 at 8:31
I've added a patch which renames _DesignDocument into _DesignDocumentDefinition.
Original comment by oliora
on 3 Sep 2013 at 3:14
Attachments:
Any update on that?
Original comment by oliora
on 19 Sep 2013 at 10:11
Alexander, your feedback would be very welcome here.
Original comment by djc.ochtman
on 20 Sep 2013 at 8:54
More than month have passed but nothing changed. Eh :(
Original comment by oliora
on 8 Nov 2013 at 9:32
> Alexander, your feedback would be very welcome here.
Going to test patches today. On first sight looks ok. Will try to backport
tests from my issue 186 patch - I have a lot of them there (:
Original comment by kxepal
on 11 Nov 2013 at 8:52
This issue has been migrated to GitHub. Please continue discussion here:
https://github.com/djc/couchdb-python/issues/229
Original comment by djc.ochtman
on 15 Jul 2014 at 7:23
Original issue reported on code.google.com by
oliora
on 2 Sep 2013 at 6:05Attachments: