How can I delete / rollback all the migrations that have been run without having to drop and setup the database
rake db:rollback
goes back just one version. How can I get it to go all the way ?
One way is :
rake db:rollback STEP=10000000
Which pretty much means hacking your way back so many steps that the migration always goes to step 0.
Another way is:
rake db:migrate VERSION=0
More references here.
You can run $ rake db:migrate:status to see all of your migrations and whether they're in the up or down state. Go to the very first migration in that list and run:
rake db:rollback VERSION=version_id_shown_by_migrate_status_list_you_just_did
Note that if you undo all migrations, all data will be lost when the columns or tables are dropped. You can then reload the migrations by doing a normal rake db:migrate
To rollback all the migrations use bin/rake:db reset.
Pay attention, if a migration can't be rolledback, rake db:reset may fails.
References here
Related
so while deploying into one test env (which has 2 instances of the server/API running), I started to receive ActiveRecord::ConcurrentMigrationError, after some digging I realize that my 2 instances run migrations separate and that causes the issue, after receiving this error no migrations are applied at all.
Checked using: rake db:migrate:status
I looked into the platform, and I found some info related to this error but I don't think are the proper solution, because the solution is to deactivate the lock introduced in rails 5 which can cause some weird issues during migrations (maybe I missed something if so, please let me know 👌).
Solution found
So the question:
Is there any way to solve this issue without deactivating the lock, or is that the proper solution (apart from only leave one of the instance instead of the 2 run the migration)?
Note: I would like to keep my migrations running automatically in both instances (just after the release) as usual.
Thx in advance 👍.
After upgrading from Rails 3 to Rails 4 the db:schema:load task is failing. I did some digging into it and found that after the upgrade when I run bundle exec rake db:schema:load the db/schema.rb file is being loaded twice. The first time it runs fine; then the second time through it fails due to a create_table force: true fails due to there being a dependency constraint on the table.
I've stripped out every additional rake task and enhance to try and rule out any of my code, but still this loads the schema.rb twice. It is always exactly twice as I am able to run it successfully on SQLite and see the same behavior there, but it runs to completion due to SQLite not enforcing the table constraints.
You are seeing it twice because in development Rails runs db tasks for test and development in the same run.
Please see the ActiveRecord::Tasks::Databasetasks file for details, especially methods #load_schema_current (this one because you were referring to it) and #each_current_configuration
You might check to be sure your Rakefile isn't loading tasks twice. When Rake registers a task with the same name as an existing task, it will run both in sequence rather than replace the old definition with the new one.
I have an application with several code based migrations (EF5 code first) and an initializer that inherits from CreateDatabaseIfNotExists then I install that application on a production machine for the first time leting CodeFirst create the database from scratch. After that I add another code based migration and generate the migration script on my development machine and apply that script on the production machine. Then when I run my app on the production machine I'm getting errors. Those errors were generated because the code on my migrations are not being executed and there are code on those migrations that must be executed (for instance I have File Stream on my db).
Then, to solve that I changed my initializer to MigrateDatabaseToLatestVersion with AutomaticMigrationsEnabled = false. That solution solved the problem of executing all migrations code on first create but now I have this problem: VS2013 migrates the database automaticaly (if I add another migration) what I expect is to have an exception because AutomaticMigrationsEnabled = false in VS2012 that is happening BUT VS2013 IS MIGRATING AUTOMATICALLY.
Why is that happening? What I'm doing wrong?
Thanks
Automatic Migrations Enabled refers to the process of trying to automatically migrate your database to match your DbContext. For example, say you create your DbContext and run it once. Then you add a new table. With Automatic Migrations, you don't need to run Add-Migration, you can just run your app again and EF will automagically modify your database (note: it doesn't do this for all schema changes, but it makes a good effort. Sometimes you will still need to use Add-Migration).
Since your initializer is set to MigrateDatabaseToLatestVersion, any time the DbContext initialized it will run all of the migrations that are available. If there is any mismatch between your DbContext and the schema your migrations generate, you'll get an exception.
It sounds like the scenario you're expecting is when there is a mismatch between your DbContext and your database, you should get an exception. If this is what you want, you should not set your initializer to MigrateDatabaseToLatestVersion.
There's a bunch of questions out there similar to this one that talk about rails plugins as a solution - but I'm not using rails, read on for more
I have a Rakefile in a sinatra project which allows me to rake db:migrate. It'll do my migration perfectly, but I'd like to pass that a flag (or write a new rake task) which does the same thing, but outputs the SQL to STDOUT and doesn't commit the changes to the database. Does anyone know how to do this?
My first thought was to try ActiveRecord logging and see if I could get the SQL out at all, but that doesn't work! Any ideas?
namespace :db do
task :migrate_sql do
require 'logger'
ActiveRecord::Base.logger = Logger.new(STDOUT)
Rake::Task['db:migrate'].invoke
# This does the migration and doesn't output SQL - so no good!
end
end
I think there isn't any easy way to do it, for the following reasons:
up, down, and change are methods which execute other methods; there isn't a global migration query string that gets built and executed
neither the statements methods (add_column, etc) expose their statements as strings; as I understand, they are implemented as connection adapter methods, and for example the mysql adapter has a add_column_sql method, while the postgresql adapter does not, and its sql is a variable inside its add_column method
So, if you really need this functionality, I think your best option is to copy the sql from the log.
I'm trying to get migrations set up in Ramaze. I'm coming from doing mostly Rails stuff, but I wanted to give something else a shot. Anyway, I've got a directory in my project called "migrations" with a start.rb file and then my migrations. Here's start.rb:
require File.expand_path('../app.rb', File.dirname(__FILE__))
require 'sequel/extensions/migration.rb'
Sequel::Migrator.apply(DB, '.')
Now, first of all, I don't know why I can't just do
Sequel::Model.plugin(:migration)
instead of that long require, but it seems to be working, so I'm not worrying about it too much. The main problem is that none of my migrations actually run. It creates the schema_info table, so I know it's trying to work, but it just can't find my 000_initial_info.rb file that's right there in the same directory.
I couldn't really find any documentation on this, so this is my own solution. I'd love to hear other solutions as well if I'm just going about this all wrong. Thanks for any help!
You can't use Sequel::Model.plugin :migration because migration is not a model plugin, it is a core extension. This will work:
Sequel.extension :migration
Sequel comes with the bin/sequel tool that you can use to run migrations with the -m switch:
sequel -m /path/to/app/migrations
Unless you have special needs, I recommend using that.
One of the problems with your setup might be that you started your migrations at 000. Start them at 001 and it may work better.
There's rdoc documentation for the Migrator:
http://sequel.rubyforge.org/rdoc-plugins/classes/Sequel/Migrator.html
Here's my solution:
http://github.com/mwlang/ramaze-sequel-proto-experimental
Run "rake -T" to see the various db and migrate tasks I've written."
I use this "experimental" as my ramaze project template at the moment.