couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Lehnardt <...@apache.org>
Subject Re: Modifying fields
Date Thu, 12 Jun 2008 22:21:17 GMT

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
--

Mime
View raw message