couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Cloudant Query
Date Fri, 27 Jun 2014 21:55:47 GMT
On Jun 27, 2014, at 5:07 PM, Alexander Shorin <kxepal@gmail.com> 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

Mime
View raw message