On Tue, Feb 10, 2009 at 10:19 PM, Jeff Hinrichs - DM&T <dunde...@gmail.com>wrote:
> Just a few comment to get things started. > > On Tue, Feb 10, 2009 at 5:59 PM, Paul Davis <paul.joseph.da...@gmail.com> > 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 benefits). Also, why would it matter if the resulting views are heterogeneous? After all, views themselves can be a completely heterogeneous set of values.
