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