On Tue, Feb 22, 2011 at 1:07 PM, Caolan McMahon <[email protected]> wrote: > An alternative, which avoids caching modules between requests: > https://github.com/caolan/couchdb/commit/76c4f8ef9ab719b3d5cae22255197d06d1395756 > > I'd prefer if we did cache modules between requests, but this would > still solve my problems ;) > > > On 22 February 2011 17:20, Caolan McMahon <[email protected]> wrote: >> I can see the case for not wanting to store state on modules between >> requests, as this could break caching rules for those resources. Even >> though there is a performance hit. How would you know if the results >> for a show or list function had changed? >> >> It also sounds like this would be unreliable anyway since there are >> multiple JS processes. However, I think we must have caching between >> require()'s within a single request, as otherwise some modules will >> not work and we can't handle circular dependencies. >> >> The question is, should CouchDB enforce the fact that applications >> should not store state between requests (except for caching) and take >> the performance hit, or should this be left to commonjs module >> developers? >> >> I assume freezing modules would cancel out the benefits of increased >> module compatability... >> >> >> On 22 February 2011 16:57, Paul Davis <[email protected]> wrote: >>> On Tue, Feb 22, 2011 at 11:47 AM, Caolan McMahon >>> <[email protected]> wrote: >>>> As some of you may know, I've been working on a couchapp framework >>>> which makes heavy use of commonjs modules (http://kansojs.org). While >>>> developing this I've run into a number of issues which prevent the use >>>> of some modules, and makes writing my own more difficult: >>>> >>>> 1. Modules are not cached - eval'ing a complex application, consisting >>>> of many modules on each request would have an impact on performance. >>>> It also means you can't use modules which use the module object to >>>> store state. This is commonly used by template libraries to store >>>> loaded templates in a cache, or 'memoize' expensive functions. >>>> >>>> 2. Circular dependencies blow the stack - Its not possible to require >>>> module A from module B, if module B also requires module A. This >>>> happens more often than you might think, and is handled by other >>>> require() implementations by setting the cached module to an empty >>>> object before eval'ing it. The fix for this requires a module cache to >>>> be in place. >>>> >>>> >>>> Since these are really hindering progress, I've forked on github and >>>> committed my proposed patches with associated tests: >>>> https://github.com/caolan/couchdb/compare/7f553e82ef...6c66675a23 >>>> >>>> Please, if you have time, review the code and provide me with your >>>> feedback. >>>> >>>> >>>> Thanks, >>>> >>>> Caolan >>>> >>> >>> The circular dependency section looks good. >>> >>> The bit on caching and testing that things are cached is not good on >>> the other hand. The way that JS processes are used you can never be >>> sure if it'll be the same os process handling the request. In the test >>> suite, its more than likely to be the same OS process because of how >>> the server gets restarted often and there's a single serialized >>> client. >>> >>> I'm a bit iffy on whether we should cache modules because that'd be a >>> pretty easy place to break view updates and could lead to other weird >>> bits in the show/list stuff. Though I also understand the concern for >>> avoiding all the recompilation. I wonder, is it possible to freeze the >>> module maybe? >>> >> >
Looks good on first pass, though the resetModuleCache() might be better off being put into the handler for the reset command.
