On Sun, Sep 19, 2010 at 5:37 AM, Jan Lehnardt <j...@apache.org> wrote: > > On 14 Sep 2010, at 03:26, J Chris Anderson wrote: > >> >> On Sep 13, 2010, at 6:23 PM, Simon Metson wrote: >> >>> Hi James. >>> I think the thing to do is require that a document has a user field, >>> and that the value of that field matches the userCtx in the >>> validate_doc_update function. This then pushes the issue client side, and >>> makes the servers life easier. It could also be added by the front end >>> apache in the case of our deployment, I think. I can see this sort of >>> trigger thing being a good way of giving people a loaded gun aimed at their >>> foot, they certainly are in Oracle if you're not careful. >>> Cheers >>> Simon >> >> The big issue is that any code which runs on normal document updates, will >> also run during replication, as replication is just a normal client. So this >> means that adding a field will happen not just on the original client PUT >> but also when replication happens. >> >> This is why _update is a separate handler. > > Adding a required field should be idempotent (correct me if I > am wrong) so it doesn't matter that replication is an agent of > the user.
people want to add timestamps. they will call it doc.created_at and then be surprised when it behaves like doc.replicated_at the alternative of not setting doc.created_at unless it is null leaves open the potential for clients to spoof timestamps (just like they can now). so I don't see a real use case for something like this, except for trivial things like forcing that doc.foo == "foo" always, but what's the point in that? Chris > > In the past we talked about "blessing" a ddoc / update function > that would magically invoke the update function on every write. > (analog for _show and _list) and people seem to like to explore > that idea. That said, the "magic" bit worries me a little :) > > Cheers > Jan > -- > > > >> >> Chris >> >>> >>> On 9 Sep 2010, at 05:19, James Jackson wrote: >>> >>>> Hi all, >>>> >>>> Moving this from the users forum, as it appears what I'm after isn't >>>> currently available. For the security model I with to implement in a >>>> production CouchDB cluster, I would like to be able to force a field to be >>>> written to all docs based on the user context. The _update functionality >>>> is not what I am after as it requires the user to actually call it when >>>> writing a document (means security could be got-around by not calling >>>> this, and setting the required field in the passed document to something >>>> arbitrary, which would then not get caught by a validation function), and >>>> can't modify a document which is passed to it (as far as I can tell it can >>>> only modify existing documents, or create new ones). >>>> >>>> I see this ticket: >>>> >>>> https://issues.apache.org/jira/browse/COUCHDB-441 >>>> >>>> which talks about the functionality I am after, but appears to have >>>> morphed into what is now there. >>>> >>>> I am willing to implement such functionality, if it already doesn't exist, >>>> but wonder if this would be welcome in the trunk, or if there are killer >>>> pitfalls which stop this being possible. I note that in the discussion on >>>> that ticket there is talk of how to deal with multiple such >>>> modify-on-write functions, perhaps this is one area that needs discussion? >>>> >>>> In any case, I'll probably implement this for our CouchDB installation, >>>> but it would be good to make it generic and globally useful such that I >>>> can contribute it back. I know of a number of people who would like this >>>> functionality... >>>> >>>> Regards, >>>> James. >>> >> > > -- Chris Anderson http://jchrisa.net http://couch.io
