Mailing-List: contact user-help@couchdb.apache.org; run by ezmlm
Precedence: bulk
Reply-To: user@couchdb.apache.org
Received-SPF: pass (athena.apache.org: domain of paul.joseph.davis@gmail.com
 designates 209.85.132.244 as permitted sender)
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=VGkM8Cn+CBk8VHfglZRxJCdwcwzxjOyHnfIbeVEoWW0YE3ACadWTWJAhwSw9tmcOOq
         SKaRvlTE0p44Axx+Pj7Vl6zoI7XCg9vhOxAz5hdeNc8ssJODtnnaYUX8u5m4QduuwhQd
         46Seh4zhlcakftz5cAkFb6b2hAUio3wW0Odbo=
MIME-Version: 1.0
In-Reply-To: <7db9abd30902111053h7bdac9fcn9e45da6f597b0a90@mail.gmail.com>
References: <7db9abd30902111022i6c7f6385n23beba458565afb@mail.gmail.com>
	 <e2111bbb0902111037s5cb092c2xa7aef1a748c7b3ad@mail.gmail.com>
	 <7db9abd30902111053h7bdac9fcn9e45da6f597b0a90@mail.gmail.com>
Date: Wed, 11 Feb 2009 13:59:13 -0500
Message-ID: <e2111bbb0902111059m1d921c6cwc102aeb1321edeb8@mail.gmail.com>
Subject: Re: Thoughts on document/views...
From: Paul Davis <paul.joseph.davis@gmail.com>
To: user@couchdb.apache.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: 7bit

On Wed, Feb 11, 2009 at 1:53 PM, kowsik <kowsik@gmail.com> 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
> <paul.joseph.davis@gmail.com> wrote:
>> On Wed, Feb 11, 2009 at 1:22 PM, kowsik <kowsik@gmail.com> 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
>>
>