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.
On Wed, Feb 11, 2009 at 10:37 AM, Paul Davis
<[email protected]> wrote:
> On Wed, Feb 11, 2009 at 1:22 PM, kowsik <[email protected]> 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
>
