incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Dionne <dio...@dionne-associates.com>
Subject Re: Thoughts on document/views...
Date Wed, 11 Feb 2009 20:28:52 GMT
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 <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