Hi Adam and thanks for the answers. Few more questions about if you don't mind:
1. Since "The _index endpoint is mostly syntactic sugar and validation on top of _design documents." doesn't this violates REST API principles when each object must have since operational endpoint? Why the _index/_find doesn't follow common pattern as: /db/_design/ddoc/_index/foobarbaz ? 2. What were the reasons for taking MongoDB approach? I could see the one about share users market, but only. 3. If _index is a new type of storage and you took MongoDB query lang, does this means that the Index works in the same way? Fast, with in-memory cache, without need to wait when index will get built. Or it just a DSL lang for internal query server which uses couch_mrview basics? -- ,,,^..^,,, On Sat, Jun 28, 2014 at 12:27 AM, Adam Kocoloski <[email protected]> wrote: > 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
