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? >> >
