On Sun, Jan 24, 2010 at 5:28 PM, David Richardson <[email protected]> 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
