Scope in migrations can be defined by adding suffix in filename,
like: 01_a_migration.blog.rb. Such migration have blog scope.
Scope is automatically added while copying migrations from engine,
so if you want to revert all of the migrations from given engine,
you can just run db:migrate with SCOPE, like:
rake db:migrate SCOPE=blog
Example:
ActiveRecord::Migrator.migrate(path) do |migration|
migration.name =~ /User/
end
The above example will migrate only migrations with User in
the name
49ebe51 fixed copying migrations, but existing migrations would still
trigger warnings. The proper way to compare migrations is to ignore
origin lines - if migration is identical it means that we can
silently skip it, regardless where it comes from.
There was a bug in ActiveRecord::Migration.copy method, which
prevented adding special comment about the origin of migration.
Because of that, the check if migration is identical or if it's
not and should be skipped was always saying that migration is
skipped, which was causing additional useless warnings about
skipped migrations.
Removing this feature causes boost in performance when using Ruby 1.9.
Ruby 1.9 started to do implicit conversions using `to_ary` and `to_str`
in some STDLIB methods (like Array#join). To do such implicit conversions,
Ruby 1.9 always dispatches the method and rescues the NoMethodError exception
in case one is raised.
Therefore, since the whiners feature defined NilClass#method_missing, such
implicit conversions for nil became much, much slower. In fact, just defining
NilClass#method_missing (even without the whiners feature) already causes a
massive slow down. Here is a snippet that shows such slow down:
require "benchmark"
Benchmark.realtime { 1_000.times { [nil,nil,nil].join } }
class NilClass
def method_missing(*args)
raise NoMethodError
end
end
Benchmark.realtime { 1_000.times { [nil,nil,nil].join } }
At New Relic, we have hundreds of thousands of tables, and our migrations took 30 minutes without this similar patch. This cuts it down to a more reasonable amount of time.
The rescue false part is ugly, but necessary as far as I can tell. I don't know of a cross-database statement you can make that will work without trapping errors.
The main reason for this change is to fix a bug where
`validates_associated` would prevent `accepts_nested_attributes_for`
with `allow_destroy: true` from destroying invalid associated records.
This commit vastly reduces the impact of auto
explain logging when enabled, while keeping
a negligible cost when disabled.
The first implementation was based on the idea
of subscribing to "sql.active_record" when
needed, and unsubscribing once done. This is
the idea behind AR::Relation#explain. Subscribe,
collect, unsubscribe.
But with the current implementation of notifications
unsubscribing is costly, because it wipes an internal
cache and that puts a penalty on the next event.
So we are switching to an approach where a long-running
subscriber is listening. Instead of collecting the
queries with a closure in a dedicated subscriber, now
we setup a thread local.
If the feature is disabled by setting the threshold
to nil, the subscriber will call a method that does
nothing. That's totally cheap.
Rationale: As discussed with José and Jon, this convenience
shortcut is not clearly justified and it could let the user
thing the disabled EXPLAINs are related to the model instance
rather than being globally disabled.
