[
https://issues.apache.org/jira/browse/COUCHDB-441?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12738384#action_12738384
]
Curt Arnold commented on COUCHDB-441:
-------------------------------------
1. Other than possibly adding a ?include_doc(s) query parameter that would
indicate whether the modified doc needs to be returned, I would not see the
HTTP API changing. On the back-end, I'd be open to anything from a hard-coded
entry, configured Erlang handler or design doc similar to validate_doc.
2. I'm thinking there is already a different code path for replication since
I'd think that replication would preserve the existing revision id. However,
on my initial scan of couch_db:update_docs, I could not identify the code that
was responsible for generating the new revision id. If done with a design doc
approach, either the function would not be called on during replication, the
design doc would define whether it was called during replication, or the
function would be called but it could detect whether it was being called during
replication. I haven't thought of a reason that you'd want to invoke during
replication, so I'd be fine with any of them.
3. Instead of having the edit function directly modifying the document, it
could return a document that is merged into the existing document. Any
top-level key that is present in the return value from an doc-edit function
would be inserted in the document replacing any existing value for that key in
the document. However, if multiple edit functions add the same key value, the
PUT would fail with a conflict error.
> 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.
