Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 33087 invoked from network); 17 Jan 2011 12:12:33 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.3) by minotaur.apache.org with SMTP; 17 Jan 2011 12:12:33 -0000 Received: (qmail 43205 invoked by uid 500); 17 Jan 2011 12:12:31 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 42984 invoked by uid 500); 17 Jan 2011 12:12:28 -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 42976 invoked by uid 99); 17 Jan 2011 12:12:27 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jan 2011 12:12:27 +0000 X-ASF-Spam-Status: No, hits=-0.7 required=10.0 tests=FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS,T_TO_NO_BRKTS_FREEMAIL X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of fdmanana@gmail.com designates 209.85.161.52 as permitted sender) Received: from [209.85.161.52] (HELO mail-fx0-f52.google.com) (209.85.161.52) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 17 Jan 2011 12:12:21 +0000 Received: by fxm5 with SMTP id 5so5698483fxm.11 for ; Mon, 17 Jan 2011 04:12:01 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; bh=3B5NsdwlxIA6NXppvIn9bGShu2y7JNxije5km+nnmmI=; b=KNKshzf87rPaPEReMf/+zlYjKR3J++cGusdQoW9+tC1k97gu/ONJ+PFPQ4LtLTZRHv PIBrAi9ebJixaP0+1j0jf4FX0DUA67l+eGQRUSX6OjCz1FuoFVJ7He3oW9ZO5i2K9k1L Ap5xJVUt6XPN0gQHWxtOXWaesKQEHof0CcPaY= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:sender:in-reply-to:references:date :x-google-sender-auth:message-id:subject:from:to:content-type :content-transfer-encoding; b=ZD/Jzh7uBQvvPD8wFxpiLuUcvGJ3B10DQQ9dh/6W837+C02S4dFrdr1hNEi7TGxeXI Qs9pYSaHnKaGPl6CZV+XQ4Eb6p2HSIBVijcQTwccwvy9wiV8W6RauBqJM38995uWFjnb Z9W9Cj+MrDb1EwSi5OWe7Cy7n99b9DXgM7BwY= MIME-Version: 1.0 Received: by 10.223.96.202 with SMTP id i10mr4846396fan.50.1295266321194; Mon, 17 Jan 2011 04:12:01 -0800 (PST) Sender: fdmanana@gmail.com Received: by 10.223.151.12 with HTTP; Mon, 17 Jan 2011 04:12:01 -0800 (PST) In-Reply-To: References: <4D33A40C.4070307@gmail.com> Date: Mon, 17 Jan 2011 12:12:01 +0000 X-Google-Sender-Auth: An3mmL4Ajw_CKOrZQAF4hUApqAg Message-ID: Subject: Re: CouchDB key that always matches From: Filipe David Manana To: user@couchdb.apache.org Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Virus-Checked: Checked by ClamAV on apache.org I think you can do it querying with a startkey like null and an endkey like "zzzzzzz". See the view collation page on the wiki: http://wiki.apache.org/couchdb/View_collation On Mon, Jan 17, 2011 at 2:09 AM, Tristan Sloughter wrote: > Well, this is really the extent of it. Its a little more complex than wha= t I > give here (the actual key returned has 5 elements to match on). But I wan= t > exact matches of those values, instead of ranked results from a full-text > query. > > Of course, its if not possible to do something like this I guess I have n= o > other option. > > The use case is a package manager that stores both generic and os/arch > specific packages. So when asking for packages for an os/arch I want it t= o > also gather the generic packages that would have those 2 values be * or > "any" or something. > > Thanks, > Tristan > > On Sun, Jan 16, 2011 at 8:06 PM, Patrick Barnes wrote= : > >> Tristan, if you are looking to run more complex queries (particularly >> anything to do with wildcards) you should really look at couchdb-lucene. >> >> http://github.com/rnewson/couchdb-lucene >> >> -Patrick >> >> >> On 17/01/2011 1:01 PM, Tristan Sloughter wrote: >> >>> I'm looking to query my Couch database in such a way that some of the >>> fields >>> in a document can be wildcards that match any key request. Example: >>> >>> function(doc) { emit(doc.some_field, doc); } >>> >>> ?key=3D100 >>> >>> would match both the document with some_field of 100 and of some_field >>> with >>> the value *. >>> >>> Is this possible? Is there a hack way I can resolve it? >>> >>> Thanks, >>> >>> Tristan >>> >>> > --=20 Filipe David Manana, fdmanana@gmail.com, fdmanana@apache.org "Reasonable men adapt themselves to the world. =C2=A0Unreasonable men adapt the world to themselves. =C2=A0That's why all progress depends on unreasonable men."