couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dean Landolt <>
Subject Re: View Intersections
Date Wed, 11 Feb 2009 03:47:47 GMT
On Tue, Feb 10, 2009 at 10:19 PM, Jeff Hinrichs - DM&T

> Just a few  comment to get things started.
> On Tue, Feb 10, 2009 at 5:59 PM, Paul Davis <>
> wrote:
> > I've been contemplating implementing a new feature that I've been
> > wanting for awhile. There's been  some talk of implementing view
> > intersections for a bit now so I figured I'd try and give a summary of
> > what the feature would entail in terms of functionality and then the
> > necessary bits required for an implementation.
> >
> > So the original idea for view intersections was exactly what the name
> > entails: Show me the intersection between two views for a given set of
> > view query parameters. After thinking about different methods of
> > implementation I think we can extend this to be more powerful and
> > generally applicable.
> >
> > Major Hurdle 1
> > ============
> >
> > The first necessary bit of ground work would be to implement an
> > optional value index on views. The more I thought about intersecting
> > views the more I realized it was starting to look pointless. Ignoring
> > something along the lines of group_level=N in that we can join on
> > array prefixes, all views being joined would require exactly the same
> > key. Which begs the question, why not just create 1 view that emits
> > the output of the two you want intersected.
>  I would argue that returning a simple list of docids that meet the
> requirement should suffice -- in fact, the views a and b need not be
> homogenous so returning anything beyond docids could end up being a
> bigger problem than the intersection itself.

If view intersections are to be treated like regular views (as in, can you
run a _list off of them), I'd argue there's a huge difference. These
intersections could be a great way to set up kickass _lists for couchapps
that does the kind of merging not really possible with single pass views as
they are now -- essentially it offers up many of the same benefits of a
map/reduce/map paradigm without the bookkeeping headaches (among other

Also, why would it matter if the resulting views are heterogeneous? After
all, views themselves can be a  completely heterogeneous set of values.

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