How do you skip failed migrations? (rake db:migrate) - ruby-on-rails

I can't seem to find an option or anything that allows me to skip migrations.
I know what you're thinking: "you should never have to do that..."
I need to skip a migration that makes changes to specific user records that don't exist in my development database. I don't want to change the migration because it is not part of the source I am supposed to be working with. Is there a way to skip a migration or skip failed migrations?
Thanks in advance!

I think you should fix the offending migrations to be less fragile, I'd guess that a couple of if statements and perhaps a rescue would be sufficient.
But, if fixing the migrations really isn't an option, you can fake it in various ways. First of all, you could just comment out the migration methods, run rake db:migrate, and then uncomment (or revert) the offending migration.
You can also fake it inside the database but this sort of chicanery is not recommended unless you know what you're doing and you don't mind manually patching things up when you (inevitably) make a mistake. There is a table in your database called schema_migrations that has a single varchar(255) column called version; this table is used by db:migrate to keep track of which migrations have been applied. All you need to do is INSERT the appropriate version value and rake db:migrate will think that the migration has been done. Find the offending migration file:
db/migrate/99999999999999_XXXX.rb
then go into your database and say:
insert into schema_migrations (version) values ('99999999999999');
where 99999999999999 is, of course, the number from the migration's file name. Then running rake db:migrate should skip that migration.
I'd go with the second option before the third, I'm only including the "hack schema_versions" option for completeness.

I had an issue where I had a migration to add a table that already existed, so in my case I had to skip this migration as well, because I was getting the error
SQLite3::SQLException: table "posts" already exists: CREATE TABLE "posts"
I simply commented out the content of the create table method, ran the migration, and then uncommented it out. It's kind of a manual way to get around it, but it worked. See below:
class CreatePosts < ActiveRecord::Migration
def change
# create_table :posts do |t|
# t.string :title
# t.text :message
# t.string :attachment
# t.integer :user_id
# t.boolean :comment
# t.integer :phase_id
# t.timestamps
# end
end
end

This is a good way to do it for one-off errors.
db:migrate:up VERSION=my_version
This will run one specific migration's "up" actions. (There is also the opposite if you need it, just replace "up" with "down".) So this way you can either run the future migration that makes the older one (that you need to skip) work, or just run each migration ahead of it selectively.
I also believe that you can redo migrations this way:
rake db:migrate:redo VERSION=my_version
I have not tried that method personally, so YMMV.

If you have to do that, your app's migrations are messed up!
Inserts all missing migrations:
def insert(xxx)
ActiveRecord::Base.connection.execute("insert into schema_migrations (version) values (#{xxx})") rescue nil
end
files = Dir.glob("db/migrate/*")
files.collect { |f| f.split("/").last.split("_").first }.map { |n| insert(n) }

To skip all pending migrations, run this in your terminal:
echo "a = [" $(rails db:migrate:status | grep "down" | grep -o '[0-9]\{1,\}' | tr '\n' ', ') "];def insert(b);ActiveRecord::Base.connection.execute(\"insert into schema_migrations (version) values (#{b})\") rescue nil;end;a.map { |b| insert(b)}" | xclip
(For macOS use pbcopy instead of xclip)
Then CTRL-V the result inside rails console:
a = [ 20180927120600,20180927120700 ];def insert(b);ActiveRecord::Base.connection.execute("insert into schema_migrations (version) values (#{b})") rescue nil;end;a.map { |b| insert(b)}
And hit ENTER.
You can change the list of migrations you want to skip by removing them from array a before executing the line.

Instead of skip the migration you could make your migration smart, adding some IF to it, so you can check "specific users"

sometimes, it is necessary to re-fill schema_migrations table with definitely correct migrations...
ONLY FOR THIS PURPOSE i have created this method
def self.insert_missing_migrations(stop_migration=nil)
files = Dir.glob("db/migrate/*")
timestamps = files.collect{|f| f.split("/").last.split("_").first}
only_n_first_migrations = timestamps.split(stop_migration).first
only_n_first_migrations.each do |version|
sql = "insert into `schema_migrations` (`version`) values (#{version})"
ActiveRecord::Base.connection.execute(sql) rescue nil
end
end
you can copy-paste it into any model you want and use it from console
YourModel.insert_missing_migrations("xxxxxxxxxxxxxx")
(or somehow else)
where "xxxxxxxxxxxxxx" - is timestamp of migration before which you want to stop insertion (you can leave it empty)
!!! use it only if you absolutely understand what result will you get !!!

Related

Rails: How to modify data using migrations due to change in the schema

I have following two migrations:
One, Add column contextual_page_number to transcripts table:
class AddContextualPageNumberToTranscripts < ActiveRecord::Migration[5.2]
def change
add_column :transcripts, :contextual_page_number, :integer, default: 1
end
end
Second, changing the value of the previous added column contextual_page_number based on value of another column:
class ChangePageOffsetAndContextualPageNumberOfTranscripts < ActiveRecord::Migration[5.2]
def up
Firm.all.find_in_batches do |group|
group.each do |firm|
Apartment::Tenant.switch(firm.tenant) do
Transcript.where.not(page_offset: 0).each do |transcript|
transcript.update(
contextual_page_number: ((transcript.page_offset - 1) * -1),
page_offset: 1
)
end
end
end
end
end
def down
..
end
end
After running the migration, I am getting unknown attribute contextual_page_number error.
== 20211108132509 AddContextualPageNumberToTranscripts: migrating =============
-- add_column(:transcripts, :contextual_page_number, :integer, {:default=>1}) -> 0.0095s
== 20211108132509 AddContextualPageNumberToTranscripts: migrated (0.0096s) ====
== 20220113095658 ChangePageOffsetAndContextualPageNumberOfTranscripts: migrating rails
aborted! StandardError: An error has occurred, this and all later
migrations canceled:
unknown attribute 'contextual_page_number' for Transcript.
I have even tried reset_column_information, but no luck:
Apartment::Tenant.switch(firm.tenant) do
Transcript.connection.schema_cache.clear!
Transcript.reset_column_information
..
end
Any clue would be of great help, thanks.
As mentioned in one of the answer, I tried reset_column_information just right after the add_column, but that didn't worked. Finally, SQL to the rescue..
sql_cmd = "UPDATE transcripts
SET contextual_page_number = ((page_offset - 1) * -1),
page_offset = 1
WHERE page_offset != 0"
Transcript.connection.execute(sql_cmd)
You need two migration files.
First, try running the migration and check schema.rb for the table transcripts and verify that the newly added column contextual_page_number is being added or not.
Once you are sure that your new column is added, then again create a new migration like, eg: MigrateTransriptsCloningsData, and then add the desired changes in the up block, then execute db:migrate to update the required changes.
My choice would be To add a new rake task and executing it. like bundle exec rake migrate_transcripts_data:start instead of keeping that logic in the db/migrate/your_new_migration_file, choice is yours.
reset_column_information should be the correct way to resolve this sort of problem if you want to use models in a migration. This isn't without its problems though.
I suspect the issue is that you are calling it too late somehow. Put it first thing in the up method of the second migration or after the add_column in the first migration.
I may assume that the issue is in Apartment.tenant_names.
In the second migration, you are switching tenants by Apartment::Tenant.switch(firm.tenant), but I do not see similar in the first migrations. Probably tenant names are in DB, not in configs.
I am pretty sure that you may find samples of the appropriate add_column in your previous migrations.
Do not use structure migrations to modify data.
Use rake tasks, or data-migrate gem instead.
Also, do not use automatic data migrations, if you not ensure, that it working as expected on production server.
Always store data before modifications and write modification rollback code.

rails test error:"table projectname_test.destroys doesn't exist"

I just started to learn Ruby on Rails. And when I used the rails to do the test, an error occurred as:
UserTest#test_the_truth:
ActiveRecord::StatementInvalid: Mysql2::Error: Table 'eula_test.destroys' doesn't exist: SHOW FULL FIELDS FROM destroys
I don't know what is eula_test.destroys and how should I solve this problem.
check your migration files. on db/migrate.rb and db/shema.rb you can check out if you have that table.
Seems no-one has been able to answer this, but best guess based on the error you are getting it looks like you need a join table because you most likely have a "has_and_belongs_to_many" directive in both your models eula.rb and test.rb
So you need to create a migration: rails g migration CreateEulaTest
then edit the migration to include an index that tells the db to look in eula_test table for the data to join with.
you need edit your migration with the following:
def up
create_table :eula_test, :id => false do |t|
t.integer :eula_id
t.integer :test_id
end
add_index(:eula_test, [:eula_id, :test_id]
end
def down
drop_table :eula_test
end
end
Note: this table does not require it's own ID hence the :id => false
Also, the add_index portion are your foreign keys between the 2 models that allows the database to know that you are going through the table to establish your directive, such as create and destroy etc.
run rails db:migrate for rails 5 or greater, rake db:migrate <5
You may need to check your models to ensure you have the correct has_to_and_belongs_to_many settings.
It is likely you missed this part of the tutorial. Some tutorials don't explain why things are done, they just show you the code and let you figure it out.
rails db:reset should fix it :)

how i can i check the existence of the table

hy
A lot of time when i run rake db:migrate i get an error because the table user or foor or bar exist.
I try to check the existence of table, but that didn't work and i dont know why .
I use rails 3.2.2
class AddDeviseToUsers < ActiveRecord::Migration
#def self.table_exists?(users)
# ActiveRecord::Base.connection.tables.include?(users)
#end
if !table_exists?("users")
def change
create_table(:users) do |t|
## Database authenticatable
t.string :email, :null => false, :default => ""
t.string :encrypted_password, :null => false, :default => ""
end
end
end
You can check the existence of a table with the following command. This question has already been posted and answered here.
ActiveRecord::Base.connection.table_exists? 'users'
However, your code contains errors. You cannot define a method inside an if block with the syntax you're using. Put the block inside your method, instead.
def change
if !table_exists?("users")
# ...
end
end
Also, you should not be getting this kind of errors often, as you state. Migrations are applied sequentially. Creating your users table in a separate migration before adding Devise to it would take care of that problem. If you run into this problem while migrating an existing project from scratch, consider using rake db:schema:load instead.
In your command terminal type in
sqlite3 db/development.sqlite3
then you can search through your database by SQL command. Use .tables to list all tables in the database and you can see if yours is missing or not.
You can also just look at your schema file to see if the migration worked. The table along with all of it's attributes will be listed there.
You should never have multiple migrations that both try to create the same table. You also should not experience errors like this if you're working with rails migrations correctly.
The way rails migrations work is that every time you run rake db:migrate, for every migration file that runs successfully, it stores the number part of the migration file 123456789_create_users_table.rb (123456789 in this case) in a table in your db called schema_migrations. This way if a migration has already been run, it will never get run again.
It doesn't sound like you're working with rails migrations correctly. I suggest reading this thoroughly: http://guides.rubyonrails.org/migrations.html

Alter Schema in Rails 2

I need to add some columns to a table in my schema. Can someone tell me the best way to do this?
The following seems incomplete or wrong since the schema.rb file did not update to include the new column and all of the corresponding view files (edit,index,new,show) did not update to include the new column. Not to mention the bloat of all of those migration classes that get generated. Thanks
ruby script/generate migration RecordLabelToAlbums record_label:string
exists db/migrate
create db/migrate/20121130125859_record_label_to_albums.rb
Creates this:
class RecordLabelToAlbums < ActiveRecord::Migration
def self.up
end
def self.down
end
end
I then added this:
class RecordLabelToAlbums < ActiveRecord::Migration
def self.up
add_column :albums, :record_label, :text
end
def self.down
remove_column :albums, :record_label
end
end
The I ran:
rake db:migrate
Got This:
Mysql::Error: Table 'albums' already exists: CREATE TABLE albums (id int(11) DEFAULT NULL auto_increment PRIMARY KEY, created_at datetime, updated_at datetime)
The code you added is correct.
The error suggests that for some reason your system appears to think it has not yet run the original migration that created the albums table. The state of migrations (in Rails 2) is specified in a table in the database called schema_migrations -- if this gets confused then it will try to re-run migrations. I am not sure what might cause it to get confused, but I do recall this happened a couple times back in 2008 when I was using Rails 2.x.
The table is simple -- you can see what's in it from a SQL prompt -- just the names of migrations it thinks it has run, I think.
If you don't mind losing some data, you can try rake db:rollback or even rake db:reset to get back to the beginning. rake db:rollback STEP=2 will rollback the last 2 migrations.
If you need the data, correct the contents of the table by adding one or more new records referencing the migrations in app/db/migrations that may have been missed. The order is important, I think (the format changed a little in Rails 3, I don't recall how).
Any time you want to add or change the database schema, use rails to generate a migration, and then run rake db:migrate once it's ready to go.
And just asking: is there any way you can move to Rails 3. It's been out for years now, and Rails 4 is coming soon. You'll find yourself in a backwater of incompatibilities, deprecations, security and performance issues and so on if you don't take the hit and upgrade.

Rails: One migration works when I run it individually, but not in a series with other migrations

I have a series of migrations for refactoring on the upcoming release. Some of the migrations are used to move columns around.
When I run the migrations all at once, the specific column in the following example is never copied to the new place.
def up
add_column :buy_topics, :price, :integer
say_with_time 'Move price and value to buy/topics' do
bar = ProgressBar.new(Buy::Topic.count)
Buy::Topic.includes{topic}.find_each do |topic|
topic.price = topic.topic.price
topic.save
bar.increment!
end
end
remove_column :topics, :price
end
Even though the values are not copied, the columns were still created and removed successfully though.
However if I run all the migration up to the the one prior to this (e.g. rake db:migrate VERSION=XXXXXXXXn-1), and then manually run this one particular migration (rake db:migrate VERSION=XXXXXXXXn), the values are copied across.
So in summary, if I run that migration individually it works, otherwise it will not work
What could be the reason behind this?
Try doing this:
Buy::Topic.reset_column_information
For more information, look at "Using a model after changing its table" on [this page][http://api.rubyonrails.org/classes/ActiveRecord/Migration.html].

Resources