Repeated SHOW FIELDS FROM... queries with STI

The problem with using @@ variables is that they are shared across the entire ancestor chain, thus:

@@@ruby class Base
def self.columns

@@columns ||= {}

end end
class A < Base; end
class B < Base; end

A.columns[:foo] = "I'm a column!"

B.columns #=> {:foo=>"I'm a column!"}

@foca, yep, my proposed solution actually takes advantage of that "feature" of class variables. It uses a single hash for the entire inheritance hierarchy, with table names as keys and the column collections as values.

Not sure if this is concern, these queries run only once in production and in development they do not represent a bottleneck.

yeah, I'm with Jose, how many subclasses do you really have?

We have about 300 models in our app. About a third of them are subclasses. I started looking at this today because these queries popped up in some New Relic transaction traces.

According to http://blog.lukeludwig.com/index.php/2009/01/08/rails-patch-for-cac... :

"Turns out that MySQL creates a temporary table on disk for 'SHOW FIELDS' queries, so if the disk is busy with something else these queries can take awhile to complete as seen here."

In addition, the overhead can be impactful in development or during repeated test runs, where you're reloading frequently.

What do you think? If this doesn't belong in core, I can maintain my patch locally.