incubator-couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Paul Joseph Davis (JIRA)" <j...@apache.org>
Subject [jira] Commented: (COUCHDB-441) Finally implement pre-write-doc-edit handlers.
Date Mon, 03 Aug 2009 05:15:14 GMT

    [ https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738190#action_12738190
] 

Paul Joseph Davis commented on COUCHDB-441:
-------------------------------------------

Curt,

Three things that come to mind:

1. What would the API look like if it weren't an API endpoint? I just ran with what was easy
to implement, but between your's, Jason's and Chritopher's comments I'm wondering if maybe
there's another approach that is more general.

2. I'm fairly against calling mutation handlers on replication as it seems like it could very
easily lead to an inability to reach steady state. If we force clients to choose to push docs
to a handler that is OOB from replication then we alleviate such concerns.

3. I'm also fairly against the arbitrary ordering. A big understanding in the community is
that we're presenting users the ability to replicate _design docs as an entire application.
Forcing applications to write against transient undefinable situations seems like a recipe
for disaster. The question isn't if I as a design declare an edit function, its that I have
to account for any possible configuration of order of any possible input. I could see it being
very easy for two independent designers declaring mutually exclusive conditions and rending
a DB un-editable from app code.

Paul



> Finally implement pre-write-doc-edit handlers.
> ----------------------------------------------
>
>                 Key: COUCHDB-441
>                 URL: https://issues.apache.org/jira/browse/COUCHDB-441
>             Project: CouchDB
>          Issue Type: Improvement
>          Components: HTTP Interface
>    Affects Versions: 0.10
>            Reporter: Curt Arnold
>             Fix For: 0.10
>
>         Attachments: COUCHDB-441.patch
>
>
> It would be useful for auditing to have the identity of the user who inserted a new revision
and the timestamp of the operation to be inserted in the document in the same way that the
new revision number is.
> Doing this at the application level is not adequate since it would be readily spoofable
and would bypass the authentication handler.
> There is a comment in couch_db:update_docs about generating new revision ids, but I couldn't
quite comprehend what specific code was responsible for inserting the id into the document.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message