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