incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Antony Blakey <antony.bla...@gmail.com>
Subject Re: Thoughts on document/views...
Date Wed, 11 Feb 2009 20:57:28 GMT
CouchRest provides a couchrest-type attribute, which is used for  
mapping to a Ruby class. The issue I've had is that dealing with  
inheritance requires that each map guard checks the type against a  
list of  possible classes (for e.g. a subclass test). I thought (for 2  
seconds) about making couchrest-type into a vector, but that  
fossilizes the inheritance hierarchy in the data, which is a very bad  
idea.

What would be nice is a supported facility for including code in a  
design view that is shared amongst all the map/reduce functions in the  
view. Then I could code the subclass test as a shared function.

Alternatively, we could get a performance increase by formalising the  
concept of a map guard/filter. A simple case is testing a single  
attribute against a vector of values. That would deal with class/ 
subclass tests, and could be handled entirely on the couch side of the  
view processor, eliminating the need to calling the external. That  
guard could be an erlang function, defined in the design doc.

On 12/02/2009, at 6:58 AM, Robert Dionne wrote:

> 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
>>>>>
>>>>
>>
>

Antony Blakey
-------------
CTO, Linkuistics Pty Ltd
Ph: 0438 840 787

It's amazing that the one side of the conversation that survived is "I  
don't know art, but I know what I like". The reply from the artist was  
"Madam, so does a cow".
   -- Carl Kirkendall



Mime
View raw message