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.
It often takes me a a bit of thinking to decide whether or not to store different document in the same database. So, I suppose a feature like this would alleviate a possible negative side effect of that choice, by reducing the time it takes to filter out the different document types. Shooting from the hip, I'd say I like this feature! –Zach On Wed, May 13, 2009 at 9:08 AM, Jan Lehnardt <[email protected]> wrote: > Hi, > > I made views faster! :) > > I wrote a patch* that introduces the concept of a view filter. > A new design doc option acts as a document filter and > prevents a doc from getting serialized and sent to the view > server. This is useful to avoid unnecessary computation > when using views that use the `if(doc.type == "foo") {…` > pattern. > > * > http://github.com/janl/couchdb/commit/a47a4831db74e3e0400c6faaaa29984e10ac861c > > The filter works like this: > { > _id:"_design/test_foo", > language: "javascript", > options: { > filter: [{type: "foo"}, {type: "bar"}] // oh hey, proplists in JSON! :) > }, > views: { > all_docs: { // really, only all foo and bar docs > map: "function(doc) { emit(doc.integer, null); }" > } > } > }; > > If *any* of the `{field, value}`** objects match a *top level* field and > value in a document, it gets sent to the view server. > > ** Yeah, `field` is not hardcoded to `type`, so if you use `class:"foo"`, > this patch works for you. > > A few notes: > > - It would be nice if we could extend this so… > No — I don't like to add any more bells an whistles to this as > eventually this will lead to pure Erlang views which we want > to get anyway. > > - In the light of other view server improvements, this might prove > to gain only marginal speed. > > - Can we have a filter per view, not a filter per design doc? — Not > without major reworking of the view server and with losing other > optimisations. > > I don't think I should just go and commit this without discussion. In > fact, I'd opt to only include this patch if there's demand. I'm happy > to maintain the patch outside of CouchDB for those who need that > speedup. > > Cheers > Jan > -- > >
