Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 28584 invoked from network); 4 Mar 2009 18:55:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 4 Mar 2009 18:55:22 -0000 Received: (qmail 7317 invoked by uid 500); 4 Mar 2009 18:55:20 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 7289 invoked by uid 500); 4 Mar 2009 18:55:20 -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 7278 invoked by uid 99); 4 Mar 2009 18:55:20 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 10:55:19 -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 ramkrishna.kulkarni@gmail.com designates 209.85.162.180 as permitted sender) Received: from [209.85.162.180] (HELO el-out-1112.google.com) (209.85.162.180) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 04 Mar 2009 18:55:13 +0000 Received: by el-out-1112.google.com with SMTP id s27so2547300ele.14 for ; Wed, 04 Mar 2009 10:54:52 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:mime-version:received:in-reply-to:references :date:message-id:subject:from:to:content-type :content-transfer-encoding; bh=6FgE+1BYC7Bb2g68A5iSTsr9IwPXA+LZNLIXD3GEUVQ=; b=mw6RKSRfkIyP26/ZCFu1NklJbEFPAudG+nMBS1qJrlDdtIM8BzT+CPM5AIVEqhDFfc gfjL/MJmgVb76qbX+datiPxiiiRCSefadnEcdHztAR7uR8+5W7PPrYEuFVv11zzDRKHn +boLzE1q5Eq5VKsz+ntv9GbTLTXfRXcwCJ6hE= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:content-transfer-encoding; b=mJYnBGP3ioGr4pdB1y6gwEE8WudLWVjWOY5NSbdb6zPNE4XpidK5QLTds00r1pn47M qfLErQEbfi0TnoKJdVDcQFEssNNqQjfK807GNnxUmVZrCoJwyFEjeJH9zebNbW5YJ2eX VQ/n7L2CJ/LBG7R2ZmKrnOMjhxKOUdlTXJv3o= MIME-Version: 1.0 Received: by 10.143.9.9 with SMTP id m9mr74820wfi.41.1236192891441; Wed, 04 Mar 2009 10:54:51 -0800 (PST) In-Reply-To: <64a10fff0903041023h6d05d513v139af5b585eebb52@mail.gmail.com> References: <64a10fff0903041023h6d05d513v139af5b585eebb52@mail.gmail.com> Date: Thu, 5 Mar 2009 00:24:51 +0530 Message-ID: Subject: Re: Suggestions required on app design From: Ramkrishna Kulkarni To: user@couchdb.apache.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Mar 4, 2009 at 11:53 PM, Dean Landolt wrote: > On Wed, Mar 4, 2009 at 12:34 PM, Ramkrishna Kulkarni < > ramkrishna.kulkarni@gmail.com> wrote: > >> Hello All, >> >> Please bear with me, I'm new. I have been playing with CouchDB >> recently and I find it kool! I would appreciate if someone from the >> list could answer few of my questions below. >> >> Consider I have a database-per-user design and I want to be RESTful. >> >> a) How do I list all users by just typing a URL like http://server/users/? >> b) Is there a way to specify startkey and endkey while listing such >> databases? For example: I want to list only databases of users >> starting with "a" > > > As it stands now you can use a proxy to rewrite urls to specifics, including > startkey and endkey as querystring args. > > There's been some conversation on implementing routing inside the design doc > itself to make it easy (and replicatible) to have pretty urls... > > But I'd still argue you'll need some sort of rewriting at the proxy level to > allow http://server/users -- if there's routing in the design doc, it should > probably be limited to http://server///... to prevent > malicious (or accidental) httpd hijacking. > I see. Makes sense. But having routing inside design doc would be great. >> >> >> I know this is possible if there is sinlge "users" database with a >> document for each user with _id=user-id. >> >> Further, consider I have database-per-blog as well (assume this is a >> simple blog application). >> a) How do I create something like view (views I believe cannot be run >> across databases) so that whenever a user resource is requested, I >> return all blogs written by that user in addition to user information? >> Basically links to all blog resources. >> >> Probably this logic should be in the application. Fire two queries, >> one to get user data and another to get blogs? > > > If you plan on splitting these across dbs, it sounds like you'll need an > administrative db to keep the users/blogs metadata. You could map over that > with ease. > I'm leaning towards making multiple client requests instead. But your idea sounds interesting. >> >> >> The reason I'm trying to do this is because I'm bit scared about >> having data in just couple of huge files. I would rather have data >> spread out in several smaller files. > > > What's the worry? > I'm not a file system expert but I'm worried about file corruption. In the worst case, if data is split across files, its not that bad compared to huge files getting corrupted. I'm not talking about CouchDB. Let's say bad blocks. I have also read in one of the mail threads that its good from performance point of view as it makes concurrent writes possible. >> >> >> Probably there are better ways to do this. Please let me know. >> >> Thanks, >> Ram >> >