Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.198.227 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:content-transfer-encoding:content-disposition
         :references;
        b=a4QPzcx2yXXDyOB69kh+0J4cERwGeTH9qQasSaoXeGmfV5lOm42gcBRzh8EYM82bbu
         NJkHePc6WzAx35ikyTD+fM5Gy/PGA/AFuizfdfwRVpRyMw/w3L0boMLitsrLeqp0wd8o
         VzoQz/i4TcafDuHYZoikv5HmSQ+pOFDOYah7I=
Message-ID: <e2111bbb0812280636h363420c1h644e1bdc0cc2a018@mail.gmail.com>
Date: Sun, 28 Dec 2008 09:36:13 -0500
From: "Paul Davis" <paul.joseph.davis@gmail.com>
To: user@couchdb.apache.org
Subject: Re: newbie question #1
In-Reply-To: <9D00C4A1-189E-4263-8978-DC86FFDB6691@pobox.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
References: <98979283-BB61-4D15-AF05-196979FA42BC@pobox.com>
	 <e2111bbb0812280526q2766d197ld38f250d25d8e890@mail.gmail.com>
	 <7127C806-65EA-4C3E-94A4-EE9E1390C38C@pobox.com>
	 <e2111bbb0812280600v50a1f34cxd03d9a25868946de@mail.gmail.com>
	 <9D00C4A1-189E-4263-8978-DC86FFDB6691@pobox.com>

[snip]
> I read the view docs (and have other questions there, like if the M/R is
> distributed across a cluster - I've used M/R w/ Hadoop, so I come w/ a set
> of assumptions...)  and I saw that it doesn't *appear* that the key or id is
> injected in the view doc, which of course brings up an obvious question :)

The CouchDB implementation of Map/Reduce (specifically reduce) is a
bit different the the canonical implementation. Mostly this is a
result of being stored in a btree and Damien's cleverness.

[snip]

>>
>> I don't follow.
>
> Suppose I wanted to ensure that my data isn't modified - I could produce a
> cryptographic signature of my JSON doc, add that to the doc, and then store
> it.  But when it comes back, it now has two magical fields added - _id and
> _rev - which I'd have to remove before re-calculating my hash.
>
> That's doable of course, but if I had some generalized library for doing
> this, there would have to be special handling when a doc is stored in
> couchdb vs other places (written to disk, tattooed on a hamster,
> whatever...)
>

I think that you're over engineering here. To make your hashing
easier, you just store all of the to-be-hashed data in a doc member.
Something like

{
    "_id": "foo",
    "_rev": "0324234",
    "stuff_to_hash": {"bar": "baz"},
    "hash": "zing!"
}

The entire envelope scheme you describe is a perfectly valid way to
use CouchDB documents, its just that it's up to *you the developer* to
enforce the envelope semantics. Honestly, that's how schema free
CouchDB is.

[snip]
>> Its not a *problem* it'd just annoy me to have to type doc.doc.foo
>> instead of doc.foo.
>
> Of course.  And I think that things that annoy me are problems :)
>

Don't we all. ;)

>>
>>
>>> Anyway, I don't want this to distract :)  It's just a subject I'm
>>> interested
>>> in, as it's a personal pet peeve...
>>>
>>> geir
>>>
>>>
>>>>
>>>>
>>>> HTH,
>>>> Paul Davis
>>>
>>>
>>
>> Apologies if I seem confused. I haven't been to sleep since a long time
>> ago.
>
> All is well - thanks for the help.   I'll keep reading and playing.
>
> geir
>
>>
>>
>> HTH,
>> Paul Davis
>
>