David E Jones wrote: > 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...
I've got a change queued that has deprecated getRelatedOne(as suggested earlier). While doing that, I also decided to go thru and fix all the remaining findByPrimaryKey, replacing with findOne. During that change, I noticed several FooWorker/FooHelper, that should really be using caching variants. A read-only fetch should be cached. A read-only web request should never hit the database. If it's a question of memory, and a particular install is throwing away cache entries too quickly, then that install needs more memory.
