SamSaffron/MiniProfiler

skip_schema_queries setting seems to be ignored in development

Opened this issue · 7 comments

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.

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.

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.

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'

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

So there are two issues:

  • skip_schema_queries is ignored for all default DB providers and only used in the fallback code (see sql_patches.rb)
  • skip_schema_queries is hard-coded to true in production and false everywhere else (see railtie.rb)

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

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.

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.