On Jun 27, 2014, at 2:12 PM, Benjamin Young <[email protected]> wrote:
>> -----Original Message----- >> From: Alexander Shorin [mailto:[email protected]] >> Sent: Thursday, June 26, 2014 11:42 AM >> To: [email protected] >> 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
