Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@couchdb.apache.org
Received-SPF: neutral (athena.apache.org: local policy)
Content-Type: text/plain; charset=us-ascii
Mime-Version: 1.0 (Mac OS X Mail 7.3 \(1878.2\))
Subject: Re: Cloudant Query
From: Adam Kocoloski <kocolosk@apache.org>
In-Reply-To: 
 <2f161f5ec5bf47a0bf5f0b87f7c12945@BLUPR06MB209.namprd06.prod.outlook.com>
Date: Fri, 27 Jun 2014 16:27:16 -0400
Content-Transfer-Encoding: quoted-printable
Message-Id: <3F599731-F3A7-4477-9000-67E17B9B7A38@apache.org>
References: 
 <CAPaJBx6Cu0NrrSznVMkTAyyLRC9er9gHy82N+NbXmTELTS=aGA@mail.gmail.com>
 <CAHdjipJE3wJ+O3yimQAt1q6aRRU-Ob1Jrquxs8axryheyaO5VQ@mail.gmail.com>
 <2f161f5ec5bf47a0bf5f0b87f7c12945@BLUPR06MB209.namprd06.prod.outlook.com>
To: dev@couchdb.apache.org

On Jun 27, 2014, at 2:12 PM, Benjamin Young <byoung@bigbluehat.com> =
wrote:

>> -----Original Message-----
>> From: Alexander Shorin [mailto:kxepal@gmail.com]
>> Sent: Thursday, June 26, 2014 11:42 AM
>> To: dev@couchdb.apache.org
>> Subject: Re: Cloudant Query
>>=20
>> 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.
>=20
> Agreed. It's unclear what the shape of these new documents are, =
whether they replicate, etc. Perhaps it's too soon to say?
>=20
> It also introduces two new endpoints `_index` and `_find` just below =
the database name which is also troublesome for long term API health.
>=20
> 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=