There are other reasons why you might not want to cache something. Quite a few of them, even without trying to be too creative.
For example: memory use. Why cache things like contact mech or order information that isn't likely to be read a very many times, but if cached would take up memory until expired and cleared (and would only be cleared if something is cleaning up expired entries) or until it makes it to the end of the LRU queue or whatever, and the whole time requiring additional resources to keep track of and making more legitimate caching less efficient. Another example: freshness. If you want to be sure the data is good, get it from the db. If it won't cause big problems to have stale data, then the cache is okay. Am I the only one who things caching everything by default (as Marc suggested) or popping out warning messages (as Adam suggests here) is a little crazy? I haven't seen anyone else speak up, so just wondering... -David On Dec 5, 2010, at 7:45 PM, Adam Heath wrote: > I've noticed several places in the code that issue a findOne(or other > find method), without using a cache, but then don't do any > modifications to the returned value. Such call sites should really > use a caching variant of the delegator. > > What I'd like to work on, is a feature, only used during development, > that would record any value looked up that wasn't cached, and wasn't > later modified, and print a warning, with an exception, to allow for a > caching variant to be added. Would others find this useful? > > Obviously, it would need to be transaction based, and would sometimes > have false-positives. Additionally, if no transaction is active, then > that automatically means a caching variant should be used.
