couchdb-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Davis <>
Subject Re: CommonJS module updates
Date Tue, 22 Feb 2011 18:14:25 GMT
On Tue, Feb 22, 2011 at 1:07 PM, Caolan McMahon
<> wrote:
> An alternative, which avoids caching modules between requests:
> 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 <> 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 <> wrote:
>>> On Tue, Feb 22, 2011 at 11:47 AM, Caolan McMahon
>>> <> wrote:
>>>> As some of you may know, I've been working on a couchapp framework
>>>> which makes heavy use of commonjs modules ( 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:
>>>> 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.

View raw message