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