Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Message-Id: <91AC8D6D-3A77-4260-9480-66781A9C683E@apache.org>
From: Jan Lehnardt <jan@apache.org>
To: user@couchdb.apache.org
In-Reply-To: <20090203212443.GA9329@uk.tiscali.com>
Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes
Content-Transfer-Encoding: 7bit
Mime-Version: 1.0 (Apple Message framework v930.3)
Subject: Re: docids starting with underscore
Date: Wed, 4 Feb 2009 12:33:40 +0100
References: <20090203212443.GA9329@uk.tiscali.com>


On 3 Feb 2009, at 22:24, Brian Candler wrote:

> I'm not sure if this is a bug, or simply a case of "don't do that"!
>
> {"couchdb":"Welcome","version":"0.9.0a739811-incubating"}
>
> I see it is possible to create documents with IDs starting with an
> underscore, such as _view, using the _bulk_docs API
>
> $ curl -X POST -d '{"docs":[{"_id":"_view","foo":"bar"}]}'
> http://localhost:5984/test_suite_db/_bulk_docs; echo
> {"ok":true,"new_revs":[{"id":"_view","rev":"3737122827"}]}
>
> [Aside: use of "id" and "_id" doesn't appear to be consistent, but  
> that's a
> separate discussion]

It is consistent. the field name is always `id` unless it is in a JSON
document, where it is `_id`.


> If you then try to retrieve this document using the normal GET API,  
> it barfs
> a 405 error (not surprisingly, since dbname/_view has a special  
> meaning)
>
> However it is still possible to retrieve it using multi document  
> fetch:
>
>
> $ curl 'http://localhost:5984/test_suite_db/_all_docs? 
> key="_view"&include_docs=true'
> {"total_rows":10,"offset":3,"rows":[
> {"id":"_view","key":"_view","value":{"rev":"3737122827"},
> "doc":{"_id":"_view","_rev":"3737122827","foo":"bar"}}
> ]}

This works because the matching of _view happens in the HTTP layer of
CouchDB. The `_all_docs` multi-key matching happens in the view server.


> I wonder if there is any value in the server restricting the docid?

Doc ids with an underscore are private to CouchDB. This is documented
behaviour. So "Don't do that" :) Maybe it is feasible to check for  
leading
underscores everywhere.

Cheers
Jan
--