incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: Thoughts on document/views...
Date Wed, 11 Feb 2009 18:59:13 GMT
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

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.

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

View raw message