Hi dev list, Damien,
I noticed when a database has multiple design docs with a
`validate_doc_update` function each. The validation functions
are called in the reverse string collation order of the design
document's id.
The function in `_design/b` gets executed before the one
in `_des
tabase has multiple design docs with a
> `validate_doc_update` function each. The validation functions
> are called in the reverse string collation order of the design
> document's id.
>
> The function in `_design/b` gets executed before the one
> in `_design/a`, which comes befor
seems like not a good
> thing to rely on.
>
> Paul
>
> On Sat, Jan 17, 2009 at 4:41 PM, Jan Lehnardt wrote:
>> Hi dev list, Damien,
>>
>> I noticed when a database has multiple design docs with a
>> `validate_doc_update` function each. The validation functions
>
I was unpleasantly surprised today when I tried to implement a rather
critical piece of our infrastructure: the validation to prevent
replication of certain design documents which are run on our server
node(s). It appears that validation functions don't get called at all
when a design doc
I'm writing a couchdb store for pintura [1] -- one of its features I'd
really like to push down to couch is conditional writes using the If header
and jsonquery. This would be trivial to do with a validation function if it
included the http context so's I could get at the headers. Is there any
reas
validation functions don't get
called at all when a design document is updated. I used the logging
example from the book:
http://books.couchdb.org/relax/reference/security#Update%20Validations%20Again
and this logs an entry for each update to a regular document, but is
eerily silent on up
That'd do funky things to the validation on replication because the
HTTP context would change. You should be able to do this with an
_update handler though.
Paul Davis
On Thu, Jan 21, 2010 at 11:48 AM, Dean Landolt wrote:
> I'm writing a couchdb store for pintura [1] -- one of its features I'd
>
On Thu, Jan 21, 2010 at 11:56 AM, Paul Davis wrote:
> That'd do funky things to the validation on replication because the
> HTTP context would change. You should be able to do this with an
> _update handler though.
>
>
Yep, that looks like just what I needed. Thanks Paul.
Dominic Barnes created COUCHDB-1488:
---
Summary: Allow Validation Functions to Modify Response
Key: COUCHDB-1488
URL: https://issues.apache.org/jira/browse/COUCHDB-1488
Project: CouchDB
This would mess with replication.
> Allow Validation Functions to Modify Response
> -
>
> Key: COUCHDB-1488
> URL: https://issues.apache.org/jira/browse/COUCHDB-1488
> Project: C
Dave Cottlehuber created COUCHDB-1747:
-
Summary: DSL for index creation, validation functions, etc.
Key: COUCHDB-1747
URL: https://issues.apache.org/jira/browse/COUCHDB-1747
Project: CouchDB
for index creation, validation functions, etc.
> --
>
> Key: COUCHDB-1747
> URL: https://issues.apache.org/jira/browse/COUCHDB-1747
> Project: CouchDB
> Issue Type: Improvement
>
in validation functions, new_doc does not contain the rev that was sent in the
request
---
Key: COUCHDB-294
URL: https://issues.apache.org/jira/browse/COUCHDB-294
document is written to the database which is when it gets the new rev id.
Feel free to reopen the issue with a test script that demonstrates the
erroneous behaviour (bonus points for a patch to the JavaScript or etap test
suite :).
> in validation functions, new_doc does not contain the rev t
14 matches
Mail list logo
