Stop me if there's a better way to do this already, but: One possible use case for this feature could be an app with a drawing component, maybe a powerpoint-type thing, where the images are created and stored as SVGs, but viewed (or previewed or thumbnailed) as pngs. The app would know to recreate the png or at least test for changes to the SVG when couch reports an updated rev.
Another use case could be a blog using markdown, possibly with markdown comments. The app could create and cache the HTML version for faster access, updating only when the source documents change. On the other hand, with view code like 'emit([doc.whatever, doc._id, doc._rev], null)' and using include_docs when the whole document is needed, one could accomplish this without requiring anything new from couch, albeit in a less elegant way. Just throwing it out there, but I think these use cases at least show how such a feature could be valuable. Cheers, Dan DeLeo On Mon, Jan 5, 2009 at 10:35 PM, Randall Leeds <[email protected]>wrote: > On Mon, Jan 5, 2009 at 23:07, Chris Anderson <[email protected]> wrote: > > > Again, I'm not sure that having the rev available on the view row > > makes a difference. The indexer cares about the keys and values, if > > they've changed, they've changed. > > > > This is true. However, it could be very expensive to compare the keys and > values to see if they've changed. You could put the burden on the > application developer to get around this by including some checksum in the > view, or just leverage the immutability of CouchDB's revisions and provide > it for free by returning the revision. I like this idea because it enables > this blurry use case we're all sort of imagining together while keeping the > actual map function focused on the real data that needs to be returned (as > opposed to metadata that enables some slick performance gain). > > -Randall >
