couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alexander Shorin <kxe...@gmail.com>
Subject Re: Cloudant Query
Date Fri, 27 Jun 2014 21:07:07 GMT
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 <kocolosk@apache.org> wrote:
> On Jun 27, 2014, at 2:12 PM, Benjamin Young <byoung@bigbluehat.com> wrote:
>
>>> -----Original Message-----
>>> From: Alexander Shorin [mailto:kxepal@gmail.com]
>>> Sent: Thursday, June 26, 2014 11:42 AM
>>> To: dev@couchdb.apache.org
>>> 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

Mime
View raw message