couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <>
Subject Re: Cloudant Query
Date Fri, 27 Jun 2014 22:35:43 GMT
On Sat, Jun 28, 2014 at 1:55 AM, Adam Kocoloski <> wrote:
> On Jun 27, 2014, at 5:07 PM, Alexander Shorin <> 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?

No, that's probably my lack of knowledge about how they works. I
thought that _find and another sugar on top of index querying, but I
feel now it's completely different thing.

>> 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.

Didn't wrote about user market as about something bad, but I'm glad
that you asked about bad things (: There is a doubt for the case when
users will expect _exactly_ the same behavior (even bugged) from
Cloudant Query implementation as MongoDB does. This remind the SQL
history, when major database players took the same specification, but
during marketing war started develop their own deviations and now we
have what we have - a lot of partially compatible deviations of the
same specification. Won't the history repeat itself for Cloudant Query
since the goal to share user market by sharing foreign solutions makes
Cloudant heavily depended from MongoDB company policy about plans for
their query syntax? You have to always play catch-up in cases of
bringing significant improvements or making breaking compatible

That's why I had asked about alternative solutions, especially if they
are proposed or aims to be a common standard.


View raw message