couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Document validation involving other documents
Date Mon, 25 Jan 2010 03:56:43 GMT
On Sun, Jan 24, 2010 at 5:28 PM, David Richardson <technical@enquora.com> wrote:
>> I'm wary of the procedural-controller middleware approach because I'm
>> afraid it encourages you to program as though you have transactions.
>> (Eg: change these 4 documents at the same time and hope for the best.)
> I fear I haven't communicated the usage case adequately.
> We're talking about validating a single document using a formula which depends on data
residing in one of several documents already in the database. Think rates, crew lists, technical
abbreviations, prior documents. We aren't changing anything on either the incoming document
or the data documents used for validation.
> Simply determining whether the state of the incoming document is valid.
> The validating data *could* be compiled into the validation function, but that function
would need to be updated every time the validation data changes. Possible, but inelegant.
>
>> If you are careful with asynchronous handlers, you can be careful to
>> pass the state through the database _changes feeds in a way that
>> doesn't give devs a false sense of multi-document transactions.
> If we don't validate and communicate failures back to author during the request/response
cycle, we may lose the chance to do so for a week or more. It also has financial implications
- I've seen documents worth $ 75,000 in billings that could not be processed for an extra
week until things were straightened out.
> It gets tiresome in a hurry.
>
> The documents arrive from clients that are usually not connected to the internet. This
is the common state of affairs in the mobile world.
> By definition an asynchronous handler is outside the request/response cycle, so the communication
opportunity is lost. Additionally, the validation process is no longer atomic. If that is
the eventual path, I'll hitch this wagon to a proper message broker/transaction manager any
day.

The validation wouldn't be atomic to the original write, but the state
machine model can eg: ignore pending docs in views.

I do see what you are saying about mobile browsers.

One thing would be to use couchdb validations to handle wellformedness
and an async process to handle dependencies with other docs.

There's also plans for  a security object which might do the trick for you.

The security object would be a _local document sent to the validation
function along with updates.


>
> This is exactly the usage scenario WebMachine was designed for, methinks. I've seen sporadic
references to webmachine in couchdb, including one last week I thought.
> Is anything happening there?
>

I don't think we'd be planning to embed arbitrary webmachine
controllers. We really want to avoid any kind of multi-document
transaction-like api. We also don't want writes to be blocked by other
queries. For these reasons, the async update process makes sense.

For the mobile "need to respond now" use case, I think something like
node.js would be perfect.

It would sit in front of the couch and submit the update. Then it
would listen to the changes feed until it sees the document move from
"pending" to "valid", and response to the client with OK.

Does that make sense? I know it's not CouchDB only, but it does do the trick.

Another option would be to write your own mochiweb or couchdb handler
and link it in using the config api. That is simple if you can handle
running on a custom-configured couchdb.

Chris

> cheers,
> David
>
> p.s. I hope this is of some interest to other people. I hear there's been a recent small
uptick in network activity by mobile clients on unreliable, non-homogeneous networks ;-)



-- 
Chris Anderson
http://jchrisa.net
http://couch.io

Mime
View raw message