Ruby-on-rails – exactly what does rake db:migrate do

migrationrakeruby-on-rails

Does rake db:migrate only add new migrations, or does it drop all migrations/changes and build everything new?

I think rake is throwing an error because it is trying to access a table attribute in migration 040 that was deleted in migration 042. somehow my DB and rake are out of synch and I want to fix them.

for you experts out there – is it common for rake to get out of synch with migrations? how can I avoid this (no, I do not hand-edit my schema or rake files).

Best Answer

When you use rails migrations, a table called schema_migrations is automatically created, which keeps track of what migrations have been applied, by storing the version number of each migration (this is the number that prefaces the migration name in the file name, ie db/migrate/_20090617111204__migration.rb). When you run rake db:migrate to migrate up, only migrations which have not been run previously (ie. their version is not contained in the table) will be run (for this reason, changing a migration that's already been executed will have no effect when running db:migrate). When migrating down, all versions found in schema_migrations that are greater than the version you are rolling back to will be undone.

If you need the task to behave as a method, how about using an actual method?

task :build => [:some_other_tasks] do
  build
end

task :build_all do
  [:debug, :release].each { |t| build t }
end

def build(type = :debug)
  # ...
end

If you'd rather stick to `rake`'s idioms, here are your possibilities, compiled from past answers:

This always executes the task, but it doesn't execute its dependencies:
```
Rake::Task["build"].execute
```
This one executes the dependencies, but it only executes the task if it has not already been invoked:
```
Rake::Task["build"].invoke
```
This first resets the task's already_invoked state, allowing the task to then be executed again, dependencies and all:
```
Rake::Task["build"].reenable
Rake::Task["build"].invoke
```
Note that dependencies already invoked are not automatically re-executed unless they are re-enabled. In Rake >= 10.3.2, you can use the following to re-enable those as well:
```
Rake::Task["build"].all_prerequisite_tasks.each(&:reenable)
```

Rails: rake db:migrate very slow on Oracle

After all migrations are applied to database then rake db:migrate calls db:schema:dump task to generate schema.rb file from current database schema.

db:schema:dump call adapter's "tables" method to get the list of all tables, then for each table calls "indexes" method and "columns" method. You can find SQL SELECT statements that are used in these methods in activerecord-oracle_enhanced-adapter gem's oracle_enhanced_adapter.rb file. Basically it does selects from ALL% or USER% data dictionary tables to find all the information.

Initially I had issues with original Oracle adapter when I used it with databases with lot of different schemas (as performance might be affected by the total number of table in the database - not just in your schema) and therefore I did some optimizations in Oracle enhanced adapter. It would be good to find out which methods are slow in your case (I suspect that it could be either "indexes" or "columns" method which is executed for each table).

One way hoe to debug this issue would be if you would put some debug messages in oracle_enhanced_adapter.rb file so that you could identify which method calls are taking so long time.

Best Answer

Related Solutions

Ruby – How to run Rake tasks from within Rake tasks

If you need the task to behave as a method, how about using an actual method?

If you'd rather stick to rake's idioms, here are your possibilities, compiled from past answers:

Rails: rake db:migrate *very* slow on Oracle

Related Topic

If you'd rather stick to `rake`'s idioms, here are your possibilities, compiled from past answers:

Rails: rake db:migrate very slow on Oracle