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 <[email protected]> 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
<[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
