couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Kruthoff <tkruth...@blit.com>
Subject Re: Thoughts on document/views...
Date Wed, 11 Feb 2009 19:45:17 GMT
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 <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
>>>
>>


Mime
View raw message