Hi all! Thanks a lot for your answers:
Take-aways for me: 1) The warm-up does happens in CouchDB too. And the time it takes solely depends on the Hardware. But what I wanted to know is when the data is present in the disk and the Server gets restarted, how does CouchDB perform when compared to MySql in performing the Warm-up (lets define Warm-up as filling the memory with Disk data in a judicial manner). Please throw some light on this. 2) Regarding MR (view), I understand its flexibility is similar to that of any Sql system since the view could be compared to a MySql index. Please let me know if my understanding is not great :) :). Thanks for the quick replies. Great to be part of a very active user-group :) :). Thanks, Matthew On Mon, Jul 4, 2011 at 9:14 AM, Jason Smith <[email protected]> wrote: > On Mon, Jul 4, 2011 at 10:11 AM, Matthew John > <[email protected]> wrote: > > 2) I understand that all the MR queries (views) to be used in the system > has > > to be coded in the Design document. Does that mean a super-set of all > > possible queries which we might use in the System has to be coded in the > > Design doc? Can this be added on the fly (dynamic ) > > Yes. > > Query CouchDB does this: https://github.com/iriscouch/query_couchdb > > Its goal is to clone the Google App Engine query API. Given a (valid) > query, it determines the appropriate map/reduce and _view query to get > that result. If the map/reduce is not there (HTTP 404), then it will > update the design doc and re-query. > > That project is undocumented, incomplete, and the code is sloppy. > However the idea behind it is very good (if I may). > > As Jens says, in practice, like any production database, you tend to > know all of your important queries at development time. During > run-time, you just fill in the blanks for the query. > > -- > Iris Couch >
