Return-Path: Delivered-To: apmail-couchdb-user-archive@www.apache.org Received: (qmail 47837 invoked from network); 8 Jan 2009 05:09:22 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2) by minotaur.apache.org with SMTP; 8 Jan 2009 05:09:22 -0000 Received: (qmail 81165 invoked by uid 500); 8 Jan 2009 05:09:21 -0000 Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org Received: (qmail 81139 invoked by uid 500); 8 Jan 2009 05:09:21 -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 81128 invoked by uid 99); 8 Jan 2009 05:09:21 -0000 Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230) by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 07 Jan 2009 21:09:21 -0800 X-ASF-Spam-Status: No, hits=2.4 required=10.0 tests=NORMAL_HTTP_TO_IP,SPF_PASS,URIBL_RHS_DOB,WEIRD_PORT X-Spam-Check-By: apache.org Received-SPF: pass (nike.apache.org: domain of paul.joseph.davis@gmail.com designates 72.14.252.152 as permitted sender) Received: from [72.14.252.152] (HELO po-out-1718.google.com) (72.14.252.152) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 08 Jan 2009 05:09:12 +0000 Received: by po-out-1718.google.com with SMTP id b23so18426504poe.3 for ; Wed, 07 Jan 2009 21:08:51 -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=9AK0G8Y8SF2eTWX8eb/yCFc4Akhuhb9Tg9G4Y5nfjEc=; b=sgm6HWqVKNyeVaLzIR09evo3WmyyG9pZR4qe0PgHximWI+0XatghCVK6j+ivmY7Rhw kCyd3PCMKRHq8B2mMflN9KW75hIFYo/Zsr/1kOaCOvRdLpIfnMc+C1wFj3lfHQPRBP8a bh+UWZBHDc330a1oVzMgh2iymMZ2doca3DOpo= 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=hlHFvJRsKJi4SFi+MfI2OOU9nx8i39PXJp/UvNjW2rINA2txu2WzmMertuvnhUm95t jzn0bO6+x1DjXBSr2AhqIqmEfzC/JxMkdiIn8Xl6K7CRkA7ps69AoeE3oEMktfBemKI4 rs2vH8DTSOs/DF/DBNC1L2VwYPcMBVVhwCTOc= Received: by 10.141.168.2 with SMTP id v2mr11923763rvo.47.1231391330922; Wed, 07 Jan 2009 21:08:50 -0800 (PST) Received: by 10.141.75.15 with HTTP; Wed, 7 Jan 2009 21:08:50 -0800 (PST) Message-ID: Date: Wed, 7 Jan 2009 19:08:50 -1000 From: "Paul Davis" To: user@couchdb.apache.org Subject: Re: drill into a doc with a GET? In-Reply-To: <60226249-2781-43AF-86B8-17940B3B9251@koberg.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <013C8232-C1A7-4C69-8996-21C86B41B340@koberg.com> <5F4CD013-AB8B-4570-8106-6DCE08FBA550@koberg.com> <60226249-2781-43AF-86B8-17940B3B9251@koberg.com> X-Virus-Checked: Checked by ClamAV on apache.org On Wed, Jan 7, 2009 at 5:54 PM, Robert Koberg wrote: > > On Jan 7, 2009, at 10:32 PM, Paul Davis wrote: >> >> >> Remember that views are (theoretically) calculated once per doc. So >> the lookups would be extremely fast once the view is built. >> >> I haven't a good way to explain this yet, but remember that a clever >> view strategy can answer multiple query types. Try not to think of a >> view as a single select statement. I really hate comparing things >> back to SQL, but you should think of a view as being able to answer a >> class of selects that have different values in a where clause. > > given the following doc: > > {"_id": "a", "_rev": "123", "foo": {"bar": {"baz": 1}}} > > and > > http://127.0.0.1:5984/db_name/_view/view_name/by_property?key=["foo.bar", > "a"] > > to get {"baz": 1} > > I would need to send a key like 'foo.bar' - is that acceptable as a key > value. I mean if the key is used in JS like somedoc[propVar], it won't work. > But perhaps this is done in a different layer (or eval'd in some way?) and > the dot syntax will just work? > You'd have to build the dot syntax string yourself to get that working, but that shouldn't be overly difficult. > I was hoping for a way to drill into a hierarchy of a known document and > grab what I want however deep it might be from a GET (next, I will ask for > PUT and DELETE :) ). > Partial PUT and DELETE won't ever make it in directly (AFAIK). There are a couple mailing list threads debating the entire issue of partial updates. If there's a development in the JSON community as a whole for a diff format, then the last talk was that there would probably be pretty quick support for a PATCH verb. HTH, Paul Davis > thanks for sticking with me, > -Rob > >> >> >> HTH, >> Paul >