From dev-return-35023-apmail-couchdb-dev-archive=couchdb.apache.org@couchdb.apache.org Fri Jun 27 20:48:35 2014 Return-Path: X-Original-To: apmail-couchdb-dev-archive@www.apache.org Delivered-To: apmail-couchdb-dev-archive@www.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 1222C11F32 for ; Fri, 27 Jun 2014 20:48:35 +0000 (UTC) Received: (qmail 29616 invoked by uid 500); 27 Jun 2014 20:48:34 -0000 Delivered-To: apmail-couchdb-dev-archive@couchdb.apache.org Received: (qmail 29553 invoked by uid 500); 27 Jun 2014 20:48:34 -0000 Mailing-List: contact dev-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@couchdb.apache.org Delivered-To: mailing list dev@couchdb.apache.org Received: (qmail 29540 invoked by uid 99); 27 Jun 2014 20:48:34 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2014 20:48:34 +0000 X-ASF-Spam-Status: No, hits=-0.0 required=5.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of joant@lrtw.org designates 204.11.51.157 as permitted sender) Received: from [204.11.51.157] (HELO smtp.justsomehost.net) (204.11.51.157) by apache.org (qpsmtpd/0.29) with ESMTP; Fri, 27 Jun 2014 20:48:28 +0000 Received: from localhost (localhost [127.0.0.1]) by smtp.justsomehost.net (Postfix) with ESMTP id DC65E8EC2E for ; Fri, 27 Jun 2014 16:48:07 -0400 (EDT) X-Virus-Scanned: amavisd-new at jsent.ca Received: from smtp.justsomehost.net ([127.0.0.1]) by localhost (smtp.justsomehost.net [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id GtY6XTTzagu0 for ; Fri, 27 Jun 2014 16:48:06 -0400 (EDT) Received: from smtp.justsomehost.net (smtp.justsomehost.net [204.11.51.157]) by smtp.justsomehost.net (Postfix) with ESMTP id A12998EC07 for ; Fri, 27 Jun 2014 16:48:06 -0400 (EDT) Date: Fri, 27 Jun 2014 16:48:06 -0400 (EDT) From: Joan Touzet Reply-To: Joan Touzet To: dev@couchdb.apache.org Message-ID: <4722536.86.1403902086058.JavaMail.jtouzet@jtouzet> In-Reply-To: Subject: Re: Cloudant Query MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Originating-IP: [69.165.165.30] X-Mailer: Zimbra 6.0.10_GA_2692 (Zimbra Desktop/7.2.5_12038_Windows) X-Virus-Checked: Checked by ClamAV on apache.org Just wanted to make sure it's abundantly clear: Query provides a new index store for itself. It is not just a compatibility layer that ends up talking to a couchjs view server. The generated ddoc's "views" field includes field names and sort directions, which are used by the new (pure Erlang) view server to construct a new index. Hope this helps, Joan ----- Original Message ----- From: "Adam Kocoloski" To: dev@couchdb.apache.org Sent: Friday, June 27, 2014 4:25:44 PM Subject: Re: Cloudant Query On Jun 27, 2014, at 2:12 PM, Benjamin Young 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