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: <7770A5DA-9B70-4C37-9075-1D3EB1E33FDF@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: couchdb-user@incubator.apache.org
In-Reply-To: <4851B3D9.1040403@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 10:53:32 +0200
References: <48516A9B.5060401@gmail.com> <48519E04.8040304@gmail.com>
 <567B2EFA-3E14-4A4B-9C0A-F27225B8715C@apache.org>
 <4851B3D9.1040403@gmail.com>


On Jun 13, 2008, at 01:40, Brad Schick wrote:

> Thanks for the feedback.
>
>
> On 06/12/2008 03:21 PM, Jan Lehnardt wrote:
>>> 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.
> So the DB just treats each document like a string I assume? I was  
> hoping
> it actually understood the fields. If it doesn't know about fields,  
> then
> I understand that it might not be that much more efficient doing  
> things
> on the server.
>
> But I'm curious; if the Erlang code doesn't look inside documents  
> why do
> I get errors if I pass just a json array as the body of a document? It
> seems to require a json object with named pairs.

No no, CouchDB definitely looks at the JSON structure.

> My data-model is still a work in progress, so perhaps I won't really
> need to update lots documents in sequence. Mostly I've been thinking  
> of
> maintenance examples. Like, every value for some textfield needs to be
> escaped and written back to the DB after there are already a million
> documents containing that textfield in the DB.

Yeah, that's a sort of valid use-case and CouchDB is not a very good
fit for that. But if it is maintenance, it might be okay to be slower :)


> It would be interesting to know the load on the DB of doing something
> like that inside the server versus sending and receiving all million
> documents to the client.

You'd save all HTTP handling. So things would be faster. We are at a
point with CouchDB where we are working on getting it right and not
getting it fast or adding features for all edge cases. I'm not saying  
that
CouchDB will never get a feature that helps you, but it is not yet a
priority.

Cheers
Jan
--