Author: tom[at]compton.nu
[Added to the original trac issue at 8.46am, Monday, 13th October 2008]

What is the basis of your statement that caching is unneeded? Presumably the rails developers didn't add it for fun, and given that there is (judging from your patch) no easy way to turn it off it seems odd that it would never be of any use.

I can understand that it may not be a good idea for the API but are you really saying that absolutely none of our code benefits from it?

Author: openstreetmap[at]firefishy.com
[Added to the original trac issue at 8.59am, Monday, 13th October 2008]

The cache results are only used within the same web request and on the exact same query.

The patch only suites the API requests, and likely not the web requests. I'll have a go at a patch that only affects the API requests.

I would appreciate it if we could test disabling query cache for bulk queries. (response time + memory usage).

Author: tom[at]compton.nu
[Added to the original trac issue at 9.10am, Monday, 13th October 2008]

I'll have a look at it this evening.

Author: tom[at]compton.nu
[Added to the original trac issue at 4.43pm, Monday, 13th October 2008]

Having now looked at the query cache code in rails I'm very much inclined to agree that turning it off globally may be a good thing - it is stunningly bad code that is missing any attempt whatsoever to manage the size of the cache so it has the potential to eat memory like mad.

It also has at least one wonderful bug that I spotted from a simple code inspection - if you change the database inside an uncached block that the cache won't be cleared so when you leave the uncached block you will have a stale cache... So using uncached blocks in critical places is probably not a good solution for us.

Author: tom[at]compton.nu
[Added to the original trac issue at 11.17pm, Monday, 13th October 2008]

I've deployed this now so we can see how it goes.