SamSaffron / MiniProfiler

A simple but effective mini-profiler for ASP.NET MVC, ASP.NET and Ruby.
http://miniprofiler.com
1.05k stars 221 forks source link

skip_schema_queries setting seems to be ignored in development #166

Open toupeira opened 11 years ago

toupeira commented 11 years ago

I can't seem to change the skip_schema_queries setting to true in the development environment, I tried setting Rack::MiniProfiler.config.skip_schema_queries directly in the initializer and also using a Rails.configuration.after_initialize block, but I still get the schema queries in the profiler output. Is there anything I'm missing? I did restart my server several times and made sure there were no old Ruby processes hanging around.

vitaly commented 11 years ago

from what I can see in the source its only handled on "weird dbs" and the handling is funny:

      return rval if Rack::MiniProfiler.config.skip_schema_queries and name =~ /SCHEMA/

There seems to be no support for postgres for example.

toupeira commented 11 years ago

I think that check is fine since ActiveRecord is setting that SCHEMA part (in the PostgreSQL adapter too). I'm more curious about these lines in railtie.rb:

if Rails.env.development?
  c.skip_paths << "/assets/"
  c.skip_schema_queries = true
end

And further down:

c.skip_schema_queries =  Rails.env != 'production'

So unless I'm missing something skip_schema_queries seems to be hard-coded depending on the environment.

vitaly commented 11 years ago

no its not ok, it simply doesn't work. once postgres is detected this part of the code doesn't execute. those lines are only for 'unknown databases'

toupeira commented 11 years ago

Ah sorry, didn't bother to look at the rest of the file ;-)

So there are two issues:

vitaly commented 11 years ago

still no ;) its hardcoded to false in production and true everywhere else, which kind of makes sense.

toupeira commented 11 years ago

Damn, I should triple-check my comments before posting ;-)

Hard-coding for development doesn't make sense to me at all though, why should I care about the execution length of schema queries which will be cached on production anyway? And they make it hard to notice the actual queries among all the noise.

vitaly commented 11 years ago

I think the motivation is that ​ignoring schema changes is a heuristic, so in production you don't want any of that, especially as they don't really happen anyway. But you should be willing to tolerate it in development, where schema queries are a pain.