couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <>
Subject Re: equivalent of JOINs in couchdb?
Date Tue, 17 Mar 2009 13:03:58 GMT
On Tue, Mar 17, 2009 at 6:59 AM, Jan Lehnardt <> wrote:

> On 17 Mar 2009, at 10:37, Anand Chitipothu wrote:
>  On Tue, Mar 17, 2009 at 12:38 PM, Wout Mertens <>
>> wrote:
>>> On Mar 17, 2009, at 7:34 AM, Anand Chitipothu wrote:
>>>> Thanks. That was a good article.
>>>> For my understanding, let me extend the same example to a magazine
>>>> instead of blog.
>>>> A magazine will have issues, each issue will have posts and post will
>>>> have comments.
>>>> I can use the technique described in the above blog post to display
>>>> comments in each post.
>>>> What if I want to display all comments of all posts of an issue?
>>> Something like
>>> function(doc) {
>>>  if (doc.type == "post") {
>>>     map([doc.magazine, doc._id, 1], doc);
>>>  } else if (doc.type == "comment") {
>>>     map([doc.magazine,, 2], doc);
>>>  }
>>> }
>>> ? You'd need to duplicate the magazine information on the comments
>>> though.
>> Is it not possible to achieve that without adding magazine to each
>> comment?
> Not really, no. Is it an issue?

Probably not for the magazine example, but in many of cases (particularly
where the equivalent of "magazine issue" is subject to frequent change),

Of course, it's an issue easily solved by alternative view indexing. I think
couchdb-lucene can handle this just fine as is (I haven't played with it so
I can't confirm). I know there are a lot of *sqlisms* couch shouldn't
support out of the box, but after exploring JSONQuery a little further, I
can't wait for the day when I can run a JSONQuery expressions against a view
(even if it's just all_docs) in O(log n) time.

>From an HCI standpoint, I'm convinced that the most useful generic mode of
interaction with a data set is the good ol' sortable, filterable data grid.
Compound sorts and filters will never be possible on large data sets in
couch without an alternative indexing model. That's not to say the current
model isn't broadly useful (and amazingly scalable) -- but I will say there
are certain (common) classes of problem it'll never solve on its own.

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