incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Replicating partial databases, and validation
Date Sun, 15 Feb 2009 19:34:20 GMT
Hi Jens,

On 15 Feb 2009, at 20:10, Jens Alfke wrote:

> I'm interested in using CouchDB in a peer-to-peer fashion to  
> propagate content between nodes that don't necessarily trust each  
> other. The available documentation sort of runs out before getting  
> to many of the aspects I'm interested in [I am eagerly awaiting more  
> chapters of the book!] but from reading the list archives and  
> people's blog posts, it sounds like it should be do-able. I'm just  
> not clear on the details.

This is one of the primary use-cases for CouchDB, yay :)
Some details are still being fleshed out at the moment.


> • Is it possible to pull part of a database? For example, I might to  
> pull only nodes whose names start with a particular prefix, or whose  
> content contains a particular key/value pair.

Not yet. At the moment, replication is all or nothing, but
partial replication is on the roadmap. I have no estimates,
though, on when it will land.

A poor-man's workaround for now would be writing appropriate
document validation functions (see below) to disallow writes of
any unwanted documents.


> • Can the server validate the content of documents being pulled from  
> another DB? I may want to disallow updates that modify an "author:"  
> property, or whose "date:" property isn't in a valid format. Or I  
> might want to check a digital signature[1] on each incoming entry.

If you use trunk (and I hope you do :), you can create a
`validate_doc_update: "function(..." in your design doc(s)
that gets called before any write occurs. A write might be
a regular POST request or a replication coming in.


> • Likewise, can the server validate docs being posted directly,  
> outside of replication?

Same thing.


> Some sort of generic validator hook that got called on all docs  
> being added to the db, and could give thumbs up or down, would  
> suffice. One of jchris's blog posts[2] implies this exists, but he's  
> deciphering its functionality from a unit test, and as a total  
> newbie I couldn't follow the details of what this hook is capable of.

Oh hey, you got it then :)

The update validation function lets any document get written
to the database which doesn't raise an exception. You get the
old document, the new (proposed) document and HTTP request
parameters to decide if you'd like to raise an exception or not.

This could be simple date parsing, or author-overwriting. Or
checking the HTTP basic auth user against the `author`
field.

The function can not modify a doc (say strip the `author` field)
and have that save into CouchDB.


> [1] Speaking of digital signatures, above — how would I perform  
> public-key crypto operations from within a JS handler running in  
> CouchDB? Would this require writing glue libraries for SpiderMonkey,  
> to call into e.g. OpenSSL?

I'd say yes. Or we tie it in with the Erlang SSL, but crypto-enabling
our spidermonkey client might be easier.


Cheers
Jan
--


Mime
View raw message