I like temp views. It was how I got started with couch as it was easy to experiment with the knowledge that it was going to be slow for large documents. It's possible in Futon to have a warning message (big bold blinking red font) that indicates that this is for experimentation and not for production use. Part of the problem is Futon UI doesn't tell the user about temp views.
On a related note, why not spend more dev cycles parallelizing the view server to harness multiple cores to the point even the temp views scale better? I've been on this forum for a while now and until Brian recently published some concrete performance benchmarks there really haven't been much discussions (that I'm aware of) about raw couchdb view server speed (using chrome, tracemonkey, etc). As we are just approaching 0.10, I do understand that need to focus on replication, couch apps, ease of use, RESTful-ness and all the rest, while the "core" part (IMHO) has somewhat been deprioritized. This is just my observation based on the threads of discussion here. 2 cents, K. On Wed, Jul 15, 2009 at 9:19 AM, Nicholas Orr<[email protected]> wrote: > On Thu, Jul 16, 2009 at 1:57 AM, Jan Lehnardt <[email protected]> wrote: > >> >> If you like temp views, I'd like to take your concerns into consideration. > > > I like temp view for figuring stuff out. > I'm not at the stage where I can have thought and presto perfect map/reduce > materialises on the screen in a few keystrokes.I usually only have 10 max > documents in the db. > So have never run into the performance issues. > > After I've figured stuff out I create a proper view. > Then proceed to fill up the database > > Since I now use ruby for views its not going to be much use to me having a > js temp view emulator... > I like ruby syntax, its nice: emit(key,val) unless doc.name.nil? > > Guess when you get rid of temp views "as is" it'll just take a bit longer to > "try" stuff. > > Nick :) >
