On Aug 16, 2011, at 10:23 PM, Jason Smith wrote:
> On Wed, Aug 17, 2011 at 7:03 AM, Adam Kocoloski <[email protected]> wrote:
>> On Aug 16, 2011, at 5:46 PM, Randall Leeds wrote:
>>
>>> -1 on _skip_validation and new role
>>>
>>> One can always write a validation document that considers the role, no? Why
>>> can't users who need this functionality craft a validation function for this
>>> purpose? This sounds like a blog post and not a database feature.
>>
>> Blech, really?
>>
>> Q: What request do I issue to guarantee all my documents are stored in this
>> other database?
>>
>> A: Unpossible.
>>
>> Practically speaking we need it at Cloudant because we use replication to
>> move users' databases between clusters. If it's not seen as generally
>> useful that's ok, just surprising. Best,
>
> Adam, I'm conflicted. It feels presumptuous to disagree with you and
> the developers, which I've done a lot recently.
>
> Also, I too struggle with migrating data, verbatim, between servers
> (between couches, and also between Linux boxes).
>
> But to "guarantee all my documents are stored in this other database"
> is actually incoherent. It is IMHO anti-CouchDB.
Hi Jason, we're going to have to disagree on this one. Replication is really
flexible and can do lots of things that database replication has not
historically been able to do, but I think it's a sad state of affairs that it's
not possible to use replication to create a replica of an arbitrary database.
> Validation functions, user accounts (which change from couch to
> couch), and security objects (which also change from db to db, and
> couch to couch) all come together to decide whether a change is
> approved (valid). That is very powerful, and very fundamental.
> Providing this "guarantee" betrays the promise that Couch makes to
> developers.
No, it doesn't. The "guarantee" presumes you have _admin access to the target
database. Developers shouldn't give that out, just like they shouldn't give
out root access to the server itself.
> People are using validation functions for government compliance, to
> meet regulatory requirements (SOX, HIPAA). IIRC, you are proposing a
> query parameter for Couch to disregard those instructions.
Only if you have _admin access to the database, in which case you can already
bypass validation or do whatever else you want to the data in that database if
you're so inclined.
> Validation functions confirm not only authorization, but also
> well-formedness of the documents. So, again, in the real world, where
> many people use _admin accounts, adding a ?force=true parameter sounds
> dangerous.
Well, yes, it would be dangerous to use on every request.
> Do you worry whether, in the wild, people will use it more and more,
> like logging in to your workstation as root/Administrator? It
> eliminates daily annoyances but it is actually very risky behavior.
Meh. If they choose to bypass their own validation functions that's their
concern. I don't lose sleep over it.
> Finally, yes, an admin can ultimately circumvent validation functions.
> But to me, that is the checks and balances of real life. If you forget
> your BIOS password, you can physically open the box and move a jumper.
>
> I do agree about the need to move opaque data around. I disagree that
> a query parameter should allow it. I feel the hosting provider pain.
> The customer creates _design/angry with validate_doc_update:
>
> function(newDoc, oldDoc, userCtx, secObj) {
> throw {forbidden: "I am _design/angry and I hate all documents!"};
> }
>
> And now I am responsible for replicating their data, unmolested, all
> over the place.
>
> --
> Iris Couch
