From user-return-3486-apmail-couchdb-user-archive=couchdb.apache.org@couchdb.apache.org Wed Feb 11 20:30:10 2009
Return-Path:
Delivered-To: apmail-couchdb-user-archive@www.apache.org
Received: (qmail 33661 invoked from network); 11 Feb 2009 20:30:10 -0000
Received: from hermes.apache.org (HELO mail.apache.org) (140.211.11.2)
by minotaur.apache.org with SMTP; 11 Feb 2009 20:30:10 -0000
Received: (qmail 59208 invoked by uid 500); 11 Feb 2009 20:30:04 -0000
Delivered-To: apmail-couchdb-user-archive@couchdb.apache.org
Received: (qmail 59170 invoked by uid 500); 11 Feb 2009 20:30:03 -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 59159 invoked by uid 99); 11 Feb 2009 20:30:03 -0000
Received: from nike.apache.org (HELO nike.apache.org) (192.87.106.230)
by apache.org (qpsmtpd/0.29) with ESMTP; Wed, 11 Feb 2009 12:30:03 -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 dionne@dionne-associates.com designates 69.89.18.6 as permitted sender)
Received: from [69.89.18.6] (HELO outbound-mail-120.bluehost.com) (69.89.18.6)
by apache.org (qpsmtpd/0.29) with SMTP; Wed, 11 Feb 2009 20:29:53 +0000
Received: (qmail 18503 invoked by uid 0); 11 Feb 2009 20:29:31 -0000
Received: from unknown (HELO host183.hostmonster.com) (74.220.207.183)
by outboundproxy3.bluehost.com with SMTP; 11 Feb 2009 20:29:31 -0000
DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=dionne-associates.com;
h=Received:Mime-Version:In-Reply-To:References:Content-Type:Message-Id:Content-Transfer-Encoding:From:Subject:Date:To:X-Mailer:X-Identified-User;
b=bPtJto1El5xTowjob5EIsEvJLEvr9PPKb+GpJerUcSUWXBUj8ilWPBlHhJOh9Mtb/nt//nBYNT8VdKL237i6iPxVRTzPOe/RMPAtMS8qcjhAd5uJ3g1XAUFqYQNZgUFY;
Received: from h-66-167-244-224.nycmny83.dynamic.covad.net ([66.167.244.224] helo=[192.168.2.100])
by host183.hostmonster.com with esmtpa (Exim 4.69)
(envelope-from )
id 1LXLi6-0001YX-SF
for user@couchdb.apache.org; Wed, 11 Feb 2009 13:29:31 -0700
Mime-Version: 1.0 (Apple Message framework v753.1)
In-Reply-To:
References: <7db9abd30902111022i6c7f6385n23beba458565afb@mail.gmail.com> <7db9abd30902111053h7bdac9fcn9e45da6f597b0a90@mail.gmail.com>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed
Message-Id:
Content-Transfer-Encoding: 7bit
From: Robert Dionne
Subject: Re: Thoughts on document/views...
Date: Wed, 11 Feb 2009 15:28:52 -0500
To: user@couchdb.apache.org
X-Mailer: Apple Mail (2.753.1)
X-Identified-User: {2551:host183.hostmonster.com:dionneas:dionne-associates.com} {sentby:smtp auth 66.167.244.224 authed with dionne@dionne-associates.com}
X-Virus-Checked: Checked by ClamAV on apache.org
gee I don't know, you start putting them into classes next thing you
know we'll be drawing lines, making columns, and it will be b-trees
and page boundaries (RDBMS) all over again :)
It sounds interesting but I think it starts to move away from "schema-
less".
Just my .05
Bob
On Feb 11, 2009, at 2:45 PM, Troy Kruthoff wrote:
> If the overhead of views on doc creation/update is n+1 for every
> view, then I think this makes a lot of sense. Only a very small
> percentage of my views operate on all document "types", so this
> could be a huge boost for non-trivial systems (again, I know
> nothing of the actual overhead - but I'm assuming it would be
> significant... We are working on a few apps powered by couch, one
> is a CRM that currently has ~20 doc "types" and just slightly more
> views. If couch knew to only call 1 or 2 views instead of all 25,
> seems dramatic, and we still have a lot of stuff to add).
>
> I think this should be considered before 1.0 as mapper style api's
> are sprouting like weeds for every possible language (yes, couch is
> cool), and most use some form of type persistence (we've been
> baking one for a while).
>
> As for OO, inheritance, etc... Not couch's job, nor should it go
> there and it doesn't need to. Thats the app's job, even if couch
> supports _class attrib. For example, lets assume docs implement a
> _class attr and design docs implement a "classes" attr that could
> be a string or array allowing inheritance to be easily supported
> (['animal','dog','shepard']), meaning the view applies to docs with
> those _class values, but it's the app's job to track the
> inheritance chains, couch just provides the opportunity.
>
> I do not know enough about the internals to discern if the
> advantages could be realized at the view level or at the design doc
> level. My new years res was to learn erlang and help hack couch...
> not there yet, but I did loose 10 lbs ;)
>
> -- troy
>
>
>
>
> On Feb 11, 2009, at 10:59 AM, Paul Davis wrote:
>
>> On Wed, Feb 11, 2009 at 1:53 PM, kowsik wrote:
>>> Yeah, I wasn't thinking of this as an optimization per-se, but more
>>> about clarity of organizing the data. Just like _id and _ref, if
>>> each
>>> document had a _class and each view also had a _class, then it just
>>> makes it easy to understand using the
>>> class-method-operating-on-instances concept.
>>>
>>> It also makes it incredibly easy (and fun) to map these into objects
>>> in any programming language:
>>>
>>> class Comment
>>> def self.count
>>> end
>>>
>>> def self.by_author
>>> end
>>>
>>> def self.in_time_range
>>> end
>>> end
>>>
>>> Anyways, just idle thoughts.
>>>
>>> K.
>>>
>>
>> Ohhh! Gotchya. Its an interesting concept, but my response is what
>> about inheritance of types? Also, adding logic like that into CouchDB
>> could also be seen as limiting the generality of use. And there's
>> nothing to prevent a client side from doing exactly what you're
>> asking
>> for. In fact, i think there are already examples of libraries doing
>> that.
>>
>> Keep thinking on it though, its definitely interesting. Something a
>> bit more general that isn't immediately available client side could
>> make for a good discussion.
>>
>> HTH,
>> Paul Davis
>>
>>> On Wed, Feb 11, 2009 at 10:37 AM, Paul Davis
>>> wrote:
>>>> On Wed, Feb 11, 2009 at 1:22 PM, kowsik wrote:
>>>>> Just something that occurred to me and wanted to run it by you
>>>>> guys.
>>>>> For pcapr, I have a number of different types of documents in
>>>>> couch-db, some are comments, some are about the packets, etc.
>>>>> Now, I
>>>>> have views that do something like this:
>>>>>
>>>>> map: function(doc) {
>>>>> if (doc.type == 'comment') emit(...);
>>>>> }
>>>>>
>>>>> With a large set of documents and a large set of views, any new
>>>>> document or updates to document is passed to __all__ of the views
>>>>> (when the view is eventually invoked). But I "know" that my
>>>>> documents
>>>>> come in classes and that only certain views really apply to
>>>>> them. I'm
>>>>> thinking of a view as a static method on a class that gets some
>>>>> information about the instances.
>>>>>
>>>>
>>>> That's an interesting way to think about views I'd never
>>>> considered before.
>>>>
>>>>> What I'm getting at is, does it make sense to have some type of
>>>>> document "class" attribute and then have views bound to these
>>>>> classes?
>>>>> The goal, of course, being that couch-db can pre-filter a lot
>>>>> of these
>>>>> things and only run the views for the appropriate types of
>>>>> documents.
>>>>>
>>>>> Thoughts?
>>>>>
>>>>> K.
>>>>>
>>>>
>>>> My first impression is that the idea makes perfect sense but sounds
>>>> like premature optimization.
>>>>
>>>> HTH,
>>>> Paul Davis
>>>>
>>>
>