You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Repository navigation
This repository was archived by the owner on Sep 8, 2025. It is now read-only.
Enhancement: support for defining and syncing of 'validate_doc_update', 'updates' and 'shows' entities in design document #229
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.
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.
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.
Activity
djc commentedon Jul 12, 2014
From kxepal on September 02, 2013 11:25:51
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.
djc commentedon Jul 12, 2014
From oliora on September 02, 2013 12:51:34
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.
djc commentedon Jul 12, 2014
From djc.ochtman on September 02, 2013 13:31:49
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.
djc commentedon Jul 12, 2014
From oliora on September 03, 2013 08:14:08
I've added a patch which renames _DesignDocument into _DesignDocumentDefinition.
Attachment: 0012-_DesignDocument-renamed-to-_DesignDocumentDefinition.patch
djc commentedon Jul 12, 2014
From oliora on September 19, 2013 15:11:29
Any update on that?
djc commentedon Jul 12, 2014
From djc.ochtman on September 20, 2013 01:54:03
Alexander, your feedback would be very welcome here.
djc commentedon Jul 12, 2014
From oliora on November 08, 2013 13:32:33
More than month have passed but nothing changed. Eh :(
djc commentedon Jul 12, 2014
From kxepal on November 11, 2013 00:52:53
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 (: