Please reiterate, Brian. I'm not quite sure what you're getting at here: (1) people who are storing large documents in CouchDB but not indexing them at all (I guess this is possible, e.g. if the doc ids are well-known or stored in other documents, but this isn't the most common way of working)
I do agree, though, that only being able to filter at the design doc level limits the utility of view filtering. Given that a design doc is supposed to be an application's "view" of the database, would we want to encourage folks to make a different design doc for each type of data they store in the database? My gut says "one design doc per application" —but I could be all mixed up! Cheers, Zach On Thu, May 14, 2009 at 2:43 AM, Brian Candler <[email protected]> wrote: > On Wed, May 13, 2009 at 09:41:29AM -0500, Zachary Zolton wrote: >> So, this sounds like a big win for those who like to store many >> document types in the same database with a "type descriminator" field. > > ... but only if all views in the same design doc are filtered by the same > set of types. That is, you can only use it to exclude documents which are > not used by *any* view. Therefore the benefit is for: > > (1) people who are storing large documents in CouchDB but not indexing them > at all (I guess this is possible, e.g. if the doc ids are well-known or > stored in other documents, but this isn't the most common way of working) > > (2) people who have a separate design document for each "type" of object. > They would most likely get the same or better performance benefit by having > a single design document with all their views. > > I also think there are other pinch-points in view generation which need > working on, although perhaps they are not as quick wins as this one. > > For example, on my old Thinkpad X30 (mobile P3 1.2GHz), I can insert a set > of 1300 documents in ~2 secs using _bulk_docs. However the first view > request (generating ~6000 keys) takes around 35 seconds to respond. > > Regards, > > Brian. >
