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: <567B2EFA-3E14-4A4B-9C0A-F27225B8715C@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <48519E04.8040304@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: Fri, 13 Jun 2008 00:21:17 +0200
References: <48516A9B.5060401@gmail.com> <48519E04.8040304@gmail.com>


On Jun 13, 2008, at 00:07, Brad Schick wrote:

> On 06/12/2008 11:27 AM, Brad Schick wrote:
>> 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?
>>
>> ...
>>
>> 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.
>>
>>
> Follow up questions on this: Does CouchDB internally track and  
> reference
> individual fields? Or is the json for each document basically a blob  
> to
> everything except View code?

Documents are stored into native Erlang types representing each
document. Except for the view server, no-one cares about what
a document look like.

> (caveat: I know little about CouchDB internals, so the following is
> based on how I assume it might work)
>
> To complement Views, how about a concept of Modifier scripts? These
> would work in two separate stages. First, a map stage would build an
> index similar to Views. If CouchDB is able to reference individual
> fields, the map would emit a key and field names for each document. If
> CouchDB is only able to reference documents, the map would emit just a
> key for each document. Then there would be a 'modify' stage that was  
> run
> when the modifier's URI was POSTed to. The modify function would  
> accept
> arbitrary JSON from the PUT, key(s), and either individual fields (if
> possible) or  entire document(s) (if not). I'd assume the modify
> function would have to be called either once per key or with blocks of
> keys to avoid holding everything in memory at once.

Why not do just post-modify on the client with caching? I don't really  
see
the need to add that to the DB server. Note also, that the map output
can optionally be reduced (and rereduced) which allow further
computations.


> Would that be practical? Should I start learning Erlang ;)

You should start learning Erlang in any case :)

Cheers
Jan
--