incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Anderson <jch...@apache.org>
Subject Re: Some CouchDB Qs & As
Date Sun, 25 Jan 2009 17:16:45 GMT
On Sun, Jan 25, 2009 at 4:09 AM, Brian Candler <B.Candler@pobox.com> wrote:
> As a newbie, I had some questions which I still had after reading the wiki
> and the book so far, so I thought I'd do some experiments to find the
> answers.
>
> I'm just posting them here in case it's useful to anyone else, or it could
> provide some ideas when writing the book.

Brian,

Awesome work digging into details here. You asked and answered a lot
of questions I've occasionally wondered about. Most of the behavior
you uncovered seems correct, but some of it makes me curious about
other questions.

>
> (1a) Does CouchDB store the raw JSON which it receives, character by
> character, or does it convert to and from an internal representation?

We can also check to see if the various JSON representations of
unicode characters are preserved:

$ cat unicodes.json
{"slashed":"\u0444", "raw":"ф"}

$ curl -T unicodes.json http://127.0.0.1:5984/test_suite_db/unicodes
{"ok":true,"id":"unicodes","rev":"1228573312"}

$ curl http://127.0.0.1:5984/test_suite_db/unicodes
{"_id":"unicodes","_rev":"1228573312","slashed":"\u0444","raw":"\u0444"}

Looks like we canonicalize them to their escaped encodings.

> This suggests that the JSON is converted into some internal representation,
> and then converted back to JSON.
>


> (3) It is documented (but not stressed) that a document is a JSON object, as
> opposed to any JSON value, but I thought I'd check that too:
>
> $ cat test3.dat
> ["wibble","bibble"]
> $ curl -T test3.dat http://127.0.0.1:5984/test_suite_db/test3
> {"error":"error","reason":"function_clause"}
>

That error message is horrendous. I just committed a change, now you'll get:

{"error":"invalid_json_object","reason":"Document must be a JSON object"}


> OK, what about if you submit with a new content_type and/or length?
>
> So it looks like the attributes of the attachment are ignored. (This begs
> the question: is it possible to change the content_type of an attachment
> without re-uploading it? But that's probably not very useful anyway)
>

There was also talk about adding the COPY and MOVE verbs for
attachment management. I'd have to dig into the code to see if
changing the content-type will require rewriting the attachment, or if
it only requires changing the doc meta.


>
> Answer: The presence of _rev indicates whether the document already exists
> or not, so whilst _id is ignored, _rev must be removed if you are going to
> make a copy of an existing document.
>

One could probably do a whole series of experiments to see how _rev is
treated under the COPY and MOVE verbs (which are implemented for
documents). Also, some of these experiments are likely codified as
part of the test suite.

Chris

-- 
Chris Anderson
http://jchris.mfdz.com

Mime
View raw message