On Jun 27, 2014, at 5:07 PM, Alexander Shorin <[email protected]> wrote:
> 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 ? There may well be improvements to the _index API that would allow it to better conform to REST principles. I'm not sure the same applies for _find. A significant part of the power of the _find operator is its ability to select from among various indexes on the DB in order to respond to a declarative query. Scoping _find to a design document doesn't make sense. One might argue about GET vs. POST in the API but we've seen time and again that taking a complex query and URL-encoding it makes for an unfriendly experience. We started that way with our Search offering and ultimately exposed a POST variant. Did you have something else in mind regarding REST and _find? > 2. What were the reasons for taking MongoDB approach? I could see the > one about share users market, but only. You write about user market share like it's a bad thing :) Seriously though, there are certainly alternatives out there for writing declarative queries against JSON datastores, but we didn't feel strongly enough about the superiority of any of them to ignore all the developers who have recognized that MongoDB's query documents offer a pleasant and powerful way to interact with JSON(-ish) data. > 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? I'm not sure that's an accurate description of MongoDB indexing, but at any rate no, we didn't build a new index storage system. Building a Query index on Cloudant is likely going to be faster than building an equivalent Javascript MR one because we don't have to do the JSON encoding and roundtrip through couchjs, but in the end it's still the same robust couch_btree that we know so well under the hood. Cheers, Adam
