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: local policy)
Message-Id: <4E4082A9-911A-440F-9D09-5132E0FDFD16@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <48516A9B.5060401@gmail.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v919.2)
Subject: Re: Modifying fields
Date: Thu, 12 Jun 2008 23:52:19 +0200
References: <48516A9B.5060401@gmail.com>

On Jun 12, 2008, at 20:27, Brad Schick wrote:

> I've just started evaluating CouchDB and so far I'm very impressed.  
> I've
> been comparing it to Amazon's SimpleDB in particular, and couchdb  
> looks
> like a great alternative.
>
> One thing that I haven't found in the couchdb API that surprises me,
> however, it a way to directly add or modify individual fields within a
> document. For example, how would I efficiently update just one field  
> in
> a few thousand large-ish documents?
>
> Looking at the current API, it seems like I would have retrieve each
> document in its entirety, update that one field, then write back the
> entire document. I see there is a way to bulk write many documents at
> once, but that's only a small improvement. Have I missed something? If
> not, is this ability planned for the future?

Yes, that is correct. There have been discussions about allowing single
field updates or "delta updates", but none of them came up with  
satisfying
solutions and I personally think that this feature is not worth the  
hassle.
What I found in general that this request comes from too RDBMS-centric
thinking and that it might be solvable in more CouchDB-ish ways.

What exactly are you trying to do?

In any case, such an API would only be 'syntactic sugar' and would
create the same kind of load on the server. It only saves a bit of
bandwidth and client work, but CouchDB deliberately puts more
work into the client. And as long as this is not the final bottleneck in
a perfectly designed app, there's little need to optimise this.

Cheers
Jan

> My first thought was that this could be implemented this with
> server-side script functions related to views and/or with HTTP methods
> on field URIs.
>
> Thanks,
> -Brad
>