Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 78024 invoked from network); 15 Dec 2008 18:27:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 15 Dec 2008 18:27:22 -0000 Received: (qmail 15760 invoked by uid 500); 15 Dec 2008 18:27:34 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 15732 invoked by uid 500); 15 Dec 2008 18:27:34 -0000 Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: user@couchdb.apache.org Delivered-To: mailing list user@couchdb.apache.org Received: (qmail 15721 invoked by uid 99); 15 Dec 2008 18:27:34 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Dec 2008 10:27:34 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 209.85.198.224 as permitted sender) Received: from [209.85.198.224] (HELO rv-out-0506.google.com) (209.85.198.224) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 15 Dec 2008 18:27:19 +0000 Received: by rv-out-0506.google.com with SMTP id g37so2706969rvb.35 for ; Mon, 15 Dec 2008 10:26:58 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from:to :subject:in-reply-to:mime-version:content-type :content-transfer-encoding:content-disposition:references; bh=PBOtC4R0obpFfrzO/EOwyTntJxUjNNBpN4D6+0act4o=; b=U2WWrbY6jfVxhIPI06KU7P1QIdi97LjezEVe9pdSI38TvdNffkt80d1V7Zss3Z4a4g fSk8q26+qAmlgosDHaV4yxT6R0h4VkdXgPeTcVzarR0UVWo61Wmgj0/BT+YiHM4tGbkW hbwLM5tkRiSwAUxiM8vKtBSuptjgt/+FkT5yQ= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:to:subject:in-reply-to:mime-version :content-type:content-transfer-encoding:content-disposition :references; b=Y7NfRsFRzYARTQw1VNnVFZH6lyXC0qTFpt5faGS0Vd0H5OXiAMKVloiV23GlwV8VCq mmkBywyBP7KYIch3GoMD/UY9R5F87vHNDDRL0X9DK8c0qX5CvFVzMdWQTLyWeUs2LhZe Gi3mBtZu/Q96ZwSkgnvPpoGLyJcxmEau6Dxy4= Received: by 10.140.136.5 with SMTP id j5mr3849501rvd.167.1229365617986; Mon, 15 Dec 2008 10:26:57 -0800 (PST) Received: by 10.141.79.14 with HTTP; Mon, 15 Dec 2008 10:26:57 -0800 (PST) Message-ID: Date: Mon, 15 Dec 2008 13:26:57 -0500 From: "Paul Davis" To: user@couchdb.apache.org Subject: Re: Multiple search criteria with ranges In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <12C3EB1F-8F69-4998-BB83-F45564CC9F64@gmail.com> X-Virus-Checked: Checked by ClamAV on apache.org On Mon, Dec 15, 2008 at 4:28 AM, Adam Groves wrote: > Hi Paul, > > I noticed you were working on various search solutions for CouchDB. > Your EFTI project on github specifically caught my attention. Is it on > ice at the moment? > More or less. I haven't pursued it much beyond discussing ideas for it on IRC. Generally I'm waiting for a better picture on how the Erlang plugin interface will pan out. The biggest questions for me are on how to match the code with other aspects of CouchDB. Replication in particular is a bit of a stumbling block in terms of how to pursue an actual implementation. Paul > Kind regards > > Adam Groves > > 2008/12/14 Paul Davis : >> Faceted search like this isn't best supported directly in CouchDB >> itself. Its a feature that's been discussed for implementation but as >> of yet there aren't any concrete plans on what that implementation >> would look like. >> >> That being said, there's nothing keeping you from using an external >> indexer such as Solr that supports faceted searching like you're >> describing. >> >> Also, patches are welcome :D >> >> Paul Davis >> >> On Sun, Dec 14, 2008 at 12:06 PM, Dan Woolley wrote: >>> I'm researching Couchdb for a project dealing with real estate listing data. >>> I'm very interested in Couchdb because the schema less nature, RESTful >>> interface, and potential off-line usage with syncing fit my problem very >>> well. I've been able to do some prototyping and search on ranges for a >>> single field very successfully. I'm having trouble wrapping my mind around >>> views for a popular use case in real estate, which is a query like: >>> >>> Price = 350000-400000 >>> Beds = 4-5 >>> Baths = 2-3 >>> >>> Any single range above is trivial, but what is the best model for handling >>> this AND scenario with views? The only thing I've been able to come up with >>> is three views returning doc id's - which should be very fast - with an >>> array intersection calculation on the client side. Although I haven't tried >>> it yet, that client side calculation worries me with a potential document >>> with 1M records - the client would potentially be dealing with calculating >>> the intersection of multiple 100K element arrays. Is that a realistic >>> calculation? >>> >>> Please tell me there is a better model for dealing with this type of >>> scenario - or that this use case is not well suited for Couchdb at this time >>> and I should move along. >>> >>> >>> Dan Woolley >>> profile: http://www.linkedin.com/in/danwoolley >>> company: http://woolleyrobertson.com >>> product: http://dwellicious.com >>> blog: http://tzetzefly.com >>> >>> >>> >>> >> >