incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Kruthoff <>
Subject Re: Optionally including docs in view results
Date Tue, 05 Aug 2008 23:17:07 GMT
Getting the API future-proof as possible before 1.0 release is more  
important than backwards compatibility.  The main reason I am a  
proponent of a bulk_docs api supporting the REST verbs is IMHO it is  
easier to use and understand than having multiple API end-points to  
accomplish RESTful access in a performant manner.  Couch is marketing  
itself (among other things) as a RESTful database for web apps, which  
is an obvious buzzword and one that I believe will aide in the  
adoption of the technology, but the fact is we are having this  
discussion because we need more performance than what the RESTful  
access is bringing to the table.

So, to the web developer we can say:

"When you only need to access 1-5 documents for you web page, use the  
REST api.  If you need to get 100 documents, modifiy them and save  
them back, then use the bulk_load api to get the documents and the  
bulk_docs api to save them, because we are the RESTful database built  
for tomorrows web apps"

The message that I believe is more marketable, easier to understand  
and use is that you can wrap multiple REST calls into a single request  
to the server by POSTing your requests as a JSON payload to the  
bulk_docs uri when you want to achieve maximum performance (or  
_transaction, or bulk_rest, or any other name).

-- troy

On Aug 5, 2008, at 12:06 PM, Chris Anderson wrote:

> On Tue, Aug 5, 2008 at 11:26 AM, Paul Davis < 
> > wrote:
>> There was a similar idea posted on another thread that I really  
>> liked,
>> looked at implementing and got scared of because of the mentioned
>> replication stuff in bulk docs.
>> The basic idea was to be able to post something like the following  
>> to _bulk_docs
>> {
>> "put": {doc1, doc2, doc3}
>> "delete": {doc4, doc5}
>> "get": {doc6}
>> }
> This idea has its upsides, but I'm wary of breaking
> backwards-compatibility with _bulk_docs.
> However, I don't see anything wrong with the way _bulk_docs currently
> handles create/update/delete (even if it isn't RESTful).
> On IRC there have been some good arguments in favor of an include_docs
> option for view, which could be used with _all_docs and multi-key view
> requests to yield the _load_docs (fetch docs in bulk) feature.
> Also with that design Tom's original question on this thread would be
> a simple case.
> -- 
> Chris Anderson

View raw message