Mailing-List: contact couchdb-user-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: couchdb-user@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of nunojobpinto@gmail.com
 designates 66.249.92.175 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version
         :content-type:references;
        b=M0N4Ba+wSgDSIEWS6mWwjYOr058Ot486nHn3JjmgdWlYi1rt7EHKCYStP3nHJzrCae
         dXRwkCQkwMCalwuUDH8yxJC9+7EmejGHpsFHH/UksIIaA8YxIBCR/Gx7I0UveUKWOUGj
         1UFZ8fxhaMhxYeyr1AWuMtDEkD83gLo5IyGI8=
Message-ID: <30d0cf2c0811130941w62970b58s4630565206629448@mail.gmail.com>
Date: Thu, 13 Nov 2008 12:41:58 -0500
From: "Nuno Job" <nunojobpinto@gmail.com>
To: couchdb-user@incubator.apache.org
Subject: Re: dirty reads - update strategies
In-Reply-To: <291DD2C9-F426-45DD-8664-E389F01F4CCE@apache.org>
MIME-Version: 1.0
Content-Type: multipart/alternative;
	boundary="----=_Part_12673_22556101.1226598118602"
References: <242E1551-4B7E-426D-A60B-FBCA3BEE1FA1@gmail.com>
	 <291DD2C9-F426-45DD-8664-E389F01F4CCE@apache.org>

------=_Part_12673_22556101.1226598118602
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

jan is at codebits now :D

sorry for the off topic :P

On Thu, Nov 13, 2008 at 12:39 PM, Damien Katz <damien@apache.org> wrote:

> My answer is "Don't do that". Values in documents shouldn't depend on
> values in other documents, that's a better fit for a relational or OO DB. In
> your example though, CouchDB's views could be used to compute the sums.
>
> -Damien
>
>
> On Nov 13, 2008, at 12:01 PM, ara howard 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_12673_22556101.1226598118602--