From user-return-2318-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Mon Dec 22 05:03:43 2008 Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 80151 invoked from network); 22 Dec 2008 05:03:43 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 22 Dec 2008 05:03:43 -0000 Received: (qmail 64120 invoked by uid 500); 22 Dec 2008 05:03:42 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 64094 invoked by uid 500); 22 Dec 2008 05:03:42 -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 64083 invoked by uid 99); 22 Dec 2008 05:03:42 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 21 Dec 2008 21:03:42 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of antony.blakey@gmail.com designates 209.85.198.239 as permitted sender) Received: from [209.85.198.239] (HELO rv-out-0506.google.com) (209.85.198.239) by apache.org (qpsmtpd/0.29) with ESMTP; Mon, 22 Dec 2008 05:03:34 +0000 Received: by rv-out-0506.google.com with SMTP id g37so1808015rvb.35 for ; Sun, 21 Dec 2008 21:03:14 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:from:to :in-reply-to:content-type:content-transfer-encoding:mime-version :subject:date:references:x-mailer; bh=PMS3DnZPu7Mr4AMTXu/nXG1fyFiFdGu/LYYbDHlI9LA=; b=s7QdbkpxsEbQLi26eY93in4Wu9rVIvofIvLQKlwtcUbnt/9eTouJqBVyphTJ19Gwwg NjCoKmOUqc4vl5tIEXSyzUJjXguOA5kLbhXZaxZJ62pXjPw2nwdcCxZN9rSta4olZlJj QyONswUuU0Mhw6cyXSlY7RcuOaSZ+M9AiBNo0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:from:to:in-reply-to:content-type :content-transfer-encoding:mime-version:subject:date:references :x-mailer; b=R+/DQpBJpWa8P0E4YooMdWIzCIn23jLFdqD5zpkYeg8B/bAy3X0kkxOy5TdZzrY0CP nDUS6LTvcamzlTIXG0WovtOPoBNhKPtd8g5z8qVKeFM2EAGTkjhNSpP4A97pqc/D42lE b65f47uAw01EVKu3sHVWwteESAlh184sjv1TY= Received: by 10.141.48.10 with SMTP id a10mr2992963rvk.71.1229922194063; Sun, 21 Dec 2008 21:03:14 -0800 (PST) Received: from ?192.168.0.16? (ppp121-45-41-103.lns10.adl2.internode.on.net [121.45.41.103]) by mx.google.com with ESMTPS id g31sm24920904rvb.4.2008.12.21.21.03.11 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 21 Dec 2008 21:03:13 -0800 (PST) Message-Id: <5D015CE3-0C09-47C7-B3BA-A2F0799FF0E7@gmail.com> From: Antony Blakey To: user@couchdb.apache.org In-Reply-To: <4c69d7170812212051t3a12bbabh4e0d60759291c458@mail.gmail.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v929.2) Subject: Re: clustering based on 2 columns Date: Mon, 22 Dec 2008 15:33:09 +1030 References: <4c69d7170812211449w7b36084dh2e0706ee693bdc6@mail.gmail.com> <2583A30D-5B9C-4426-BCB2-4D736FDD7EAD@gmail.com> <4c69d7170812211912p779b77fexf44cd213603bd4a0@mail.gmail.com> <4c69d7170812211916p4f6fd16er2e45d06e5cbaa42d@mail.gmail.com> <4c69d7170812211927l78457bf2hb0998e4c261e057b@mail.gmail.com> <8BE1477D-84A6-45C8-A63B-0CB5F554FF63@gmail.com> <4c69d7170812212009u5c0f835cr11b4fac72f7d782b@mail.gmail.com> <2DEF6392-F32A-40E4-AC6F-A60350828FDD@gmail.com> <4c69d7170812212029p53e3b1bep283afd328a0b209b@mail.gmail.com> <4c69d7170812212051t3a12bbabh4e0d60759291c458@mail.gmail.com> X-Mailer: Apple Mail (2.929.2) X-Virus-Checked: Checked by ClamAV on apache.org On 22/12/2008, at 3:21 PM, paul jobs wrote: > /invites/_view/invites/bydate? > count=100&group=true&startkey=["2008-12-21"]&endkey=["2008-12-21",{}] > cool antony it works > *interesting adding ,{} from startkey or removing ,{} from endkey > doesnt > work That's because {} sorts after any other value, and the solution is obvious when you know that. Sorry my previous responses were misleading - I'm not working on Sunday by choice, so this thread got the dregs of my attention. BTW if you had to do a string prefix search you have to use a unicode character after the prefix as the endkey, for exactly the same reason. I've found that UTF 0xFFF8 is the last value that works. Theoretically a unicode collation sepecification could collate that character before some others - unicode collation in CouchDB hasn't been considered yet. In UTF-8 0xFFF8 is: "\xEF\xBF\xB8", which is explicitly needed in e.g. Ruby 1.8 Antony Blakey ------------- CTO, Linkuistics Pty Ltd Ph: 0438 840 787 There are two ways of constructing a software design: One way is to make it so simple that there are obviously no deficiencies, and the other way is to make it so complicated that there are no obvious deficiencies. -- C. A. R. Hoare