charveasna / couchdb-python

Automatically exported from code.google.com/p/couchdb-python
Other
0 stars 0 forks source link

Enhancement: support for defining and syncing of 'validate_doc_update', 'updates' and 'shows' entities in design document #229

Open GoogleCodeExporter opened 8 years ago

GoogleCodeExporter commented 8 years ago
I've added classes for defining and syncing of 'validate_doc_update', 'updates' 
and 'shows' entities in design document. Class covering 'lists' entity will be 
added later.
New classes called ValidateFunctionDefinition, UpdateHandlerDefinition and 
ShowFunctionDefinition. Also there is a new function 'sync_definitions' which 
syncs a list of definition subtypes. I leave the function 
ViewDefinition.sync_many for back compatibility (although it's not marked in 
documentation as deprecated because it should be discussed first), because now 
it just calls 'sync_definitions'.
Tests and documentation are updated to cover changes.

Patches are attached.
All changes could be also found at https://github.com/oliora/couchdb-python in 
design_refactoring branch.

Original issue reported on code.google.com by oliora on 2 Sep 2013 at 6:05

Attachments:

GoogleCodeExporter commented 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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
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

GoogleCodeExporter commented 8 years ago
I've added a patch which renames _DesignDocument into _DesignDocumentDefinition.

Original comment by oliora on 3 Sep 2013 at 3:14

Attachments:

GoogleCodeExporter commented 8 years ago
Any update on that?

Original comment by oliora on 19 Sep 2013 at 10:11

GoogleCodeExporter commented 8 years ago
Alexander, your feedback would be very welcome here.

Original comment by djc.ochtman on 20 Sep 2013 at 8:54

GoogleCodeExporter commented 8 years ago
More than month have passed but nothing changed. Eh :(

Original comment by oliora on 8 Nov 2013 at 9:32

GoogleCodeExporter commented 8 years ago
> 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

GoogleCodeExporter commented 8 years ago
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