Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: neutral (athena.apache.org: 74.125.46.156 is neither permitted
 nor denied by domain of ayende@ayende.com)
Message-ID: <27d8d0930811130944n1af5f45bs4c4cfe3fc563b724@mail.gmail.com>
Date: Thu, 13 Nov 2008 19:44:05 +0200
From: "Ayende Rahien" <ayende@ayende.com>
To: couchdb-user@incubator.apache.org
Subject: Re: dirty reads - update strategies
In-Reply-To: <242E1551-4B7E-426D-A60B-FBCA3BEE1FA1@gmail.com>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_25566_28390265.1226598245141"
References: <242E1551-4B7E-426D-A60B-FBCA3BEE1FA1@gmail.com>

------=_Part_25566_28390265.1226598245141
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

This is a hack, but you could use bulk_docs to do this, which would fail if
a or b were updated already.This would cause other items (that uses a or b
but not change them) to fail updating.

On Thu, Nov 13, 2008 at 7:01 PM, ara howard <ara.t.howard@gmail.com> wrote:

>
> what are people's strategies for dealing with the following scenario
>
> doc_a = get 'id_a'
>
> doc_b = get 'id_b'
>
> obj_c = { 'sum' : doc_a.x + doc_b.y }
>
> put obj_c
>
>
> this kind of thing is tricky even in a traditional RDBMS, since the default
> transaction level may or may not allow the application to see an uncommitted
> write by another transaction.
>
> the only way i can think of to get consistency from an op like the above
> would be to do
>
> bulk_put [ obj_c, doc_a, doc_b ]
>
> in other words, if you are ever going to compute values to from couch docs
> to produce another doc, it would seem that's it's required to put *all* read
> information back in order to ensure that the sources have not changed since
> the time that you read them.  the issue with this, of course, is that a
> result computed from many documents is going to cause exponential slowdown
> since the potential for overlapping writes will increase with the number of
> documents and also the size of updates themselves will increase similarly.
>
> a solution i can image is something like
>
> list = get 'some_view'
>
> obj = computed_value_from list
>
> obj[ '_depends_on' ] = list.map{|element| [element.id, element.rev]}
>
> put obj
>
>
> so basically a method to do a put with not only your rev, but that of 'n'
> dependent docs where only the [id, rev] pair for the dependent docs need be
> posted.  am i making any sense here?
>
> cheers.
>
>
>
> a @ http://codeforpeople.com/
> --
> we can deny everything, except that we have the possibility of being
> better. simply reflect on that.
> h.h. the 14th dalai lama
>
>
>
>

------=_Part_25566_28390265.1226598245141--