couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joan Touzet <>
Subject Re: Cloudant Query
Date Fri, 27 Jun 2014 20:48:06 GMT
Just wanted to make sure it's abundantly clear: Query provides a new
index store for itself. It is not just a compatibility layer that ends
up talking to a couchjs view server. The generated ddoc's "views" field
includes field names and sort directions, which are used by the new
(pure Erlang) view server to construct a new index.

Hope this helps,

----- Original Message -----
From: "Adam Kocoloski" <>
Sent: Friday, June 27, 2014 4:25:44 PM
Subject: Re: Cloudant Query

On Jun 27, 2014, at 2:12 PM, Benjamin Young <> wrote:

>> -----Original Message-----
>> From: Alexander Shorin []
>> Sent: Thursday, June 26, 2014 11:42 AM
>> To:
>> Subject: Re: Cloudant Query
>> Can we first receive a bit more better description what is Cloudant Query and
>> new Index thing first?
>> I see for now it as some sort of abstraction over view/geo/fts indexes with
>> hand-made custom query protocol and as confusion since it creates second
>> entrance point for manage the ddocs.
> Agreed. It's unclear what the shape of these new documents are, whether they replicate,
etc. Perhaps it's too soon to say?
> It also introduces two new endpoints `_index` and `_find` just below the database name
which is also troublesome for long term API health.
> I do like the idea, though! :)

Hi Ben, Alexander,

Thanks for the feedback! The _index endpoint is mostly syntactic sugar and validation on top
of _design documents. You could create these ddocs yourself by setting "language":"query"
and configuring the other fields appropriately and the _find implementation would know to
use them. As design documents they certainly do replicate. I can see where an expert CouchDB
user might balk at having another API endpoint for ddoc manipulation, but we wanted to make
sure that Query was approachable for folks who don't have a ton of background with CouchDB.

The _find endpoint does more heavy lifting. Roughly speaking it

a) determines the most appropriate index to use for the query,
b) applies any additional selector criteria on the index entries to produce the final doc
set, and
c) filters the docs to only return the requested fields.

The current version of Query does _not_ incorporate data from FTS or Geo indexes, although
I'm sure you can imagine that we're interested in doing that :)

As far as the "hand-made custom query protocol" is concerned, there's a reason we announced
it at MongoDB World. The structure of the "selector" field in the body that you POST to /db/_find
is modeled directly on the BSON that you would supply to MongoDB in db.coll.find().

Cheers, Adam

View raw message