couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dean Landolt" <>
Subject Re: joins, reprise
Date Tue, 11 Nov 2008 20:32:39 GMT
On Tue, Nov 11, 2008 at 3:08 PM, Paul Davis <>wrote:

> I think this is an interesting idea, and has mostly been done with
> client libraries. ATM, I'm leaning towards saying that this is a
> client extension and doesn't really belong in couch. There are a crap
> load of optimizations that clients could make that couch couldn't.
> I have some ideas running around in my head about doing object graph
> loading etc. Things really start to get fun on the client when you
> contemplate referencing other databases etc.
> Anyway, if you can come up with some part of this functionality that
> *must* be done server side and has a big enough use case, ideas for
> patches are always welcome :D

I didn't think of it that way, but I agree. Perhaps a querytools plugin
would be in order when the plugin system lands, but this is probably best
left to the client. Does anybody know if jquery.couch does something like
this? If not, I'll have a go at hacking it in.

> Paul
> On Tue, Nov 11, 2008 at 2:57 PM, Dean Landolt <>
> wrote:
> > I know this join discussion has come up again and again, and with
> multi-key
> > get it's really not that hard to do a join in two steps. But I was
> playing
> > with include_docs and it got me thinking -- couldn't there be a
> dereference
> > parameter on views that acted like include docs? So you could pass in
> > ?dereference=tags, for instance, and in the return the view could grab
> all
> > tag attributes and dereference them if their value is a string containing
> an
> > existing _id. This would be a *real* join, all without any complicated
> > accounting -- and it would put an end to the whole *but sql can do
> this*...
> > whining.
> >
> > Bonus points for being able to pass in a list of dereference attributes
> > (?dereference=[tags,comments] or ?dereference=tags&dereference=comments)
> and
> > even better, if the given attribute's value is a list, iterating over it
> and
> > dereferencing any string containing an existing _id. This would be far
> nicer
> > than sql joins -- you would essentially get real many-to-manies sans
> > join-table awkwardness.
> >
> > Does this seem logical? Doable?
> >

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message