I have an issue with my Rails app database which now prevents me from completing any migrations.
I've run the following on my command line with the following results -
PRAGMA table_info(events);
0|id|INTEGER|1||1
1|title|varchar|0||0
2|location|varchar|0||0
3|date|date|0||0
4|time|time|0||0
5|description|text|0||0
6|organised_by|varchar|0||0
7|created_at|datetime|1||0
8|updated_at|datetime|1||0
9|user_id|integer|0||0
10|image_file_name|varchar|0||0
11|image_content_type|varchar|0||0
12|image_file_size|integer|0||0
13|image_updated_at|datetime|0||0
14|category_id|integer|0||0
15|url|varchar|0||0
16|number_of_spaces|integer|0||0
17|price|integer|0||0
18|is_free|boolean|0||0
19|organiser_profile|url|0||0
The issue here is with No 19 on this table -
19|organiser_profile|url|0||0
Url is not an acceptable data type which was inputted in error. I believe this is the stumbling block preventing my database from committing any further migrations.
I'm fairly new to Rails and have never manually amend a database before. What I want to do is the following -
Delete / remove / dump - No 19 from my Events table. The entire
line has to be gone.
Check what is in the database before I perform a rake db:drop (this app is in development so there won't be
much
Before I perform the following action -
bundle exec rake db:drop db:create db:migrate, I want to briefly understand what consequences could come from this
I'm pretty sure this is what is required to fix this issue and allow me to perform migrations again and move forward with my app. I've never done any of the above before and would be extremely grateful for any assistance on this process.
You're not in production yet or in danger of losing valuable information so just check out the db file from github from before the erroneous migration.
git checkout <commit> file
Then fix the migration that's erroneous then run migrations again with rake db:migrate. There's no need in this case to be trying to manually edit the table from the command line, unnecessary.
Related
The problem is the following:
I have db/seed.rb full of initial data.
One of migrations depends on data this seed provides.
I'm trying to deploy my app from empty db.
Result is:
RAILS_ENV=production rake db:migrate - fails due to lack of initial data
RAILS_ENV=production rake db:seed - fails due to pending migrations
I wanted to somehow tell rake to ignore pending migrations, but unable to do it so far.
UPDATE (due to additional experience)
Sometimes migrations and model code goes out of sync, so migrations are not being run.
To avoid this problem recently used redefining of model in migrations:
# reset all callbacks, hooks, etc for this model
class MyAwesomeModel < ActiveRecord::Base
end
class DoSomethingCool < ActiveRecord::Migration
def change
...
end
end
I am not very sure if this will help you. But I was looking for something and found this question. So it looks like this might help:
In RAILS_ROOT/config/environments/development.rb
Set the following setting to false:
# NOTE: original version is `:page_load`
config.active_record.migration_error = false
In my situation it now does not show the pending migration error anymore. Should work for rake tasks and console for the same environment as well.
Source in rails/rails
Rename the migration dependent on the data from:
20140730091353_migration_name.rb
to
.20140730091353_migration_name.rb
(add a dot at the start of the filename)
Then run rake db:seed (it will no longer complain on the pending migrations) and then rename back the migration.
If you have more migrations following after, you have to rename all of them or just move it temporary away.
Rails stores migration information in a table called schema_migrations.
You can add the version from your migration into that table to skip a specific migration.
The version is the number string which comes before the description in the file name.
[version]_Create_Awesome.rb
I had a similar issue. I commented out the add_column lines and ran the rake db:migrate commands and then removed the comment when I will need it for the testing or production environment.
There is no way unless you monkey patch the Rails code. I strongly advise you to fix your migrations instead.
A migration should not depend on the existence of some data in the database. It can depend on a previous migration, but of course absolutely not on the data on the db.
If you came across the "pending migrations" issue when trying to seed your data from within a running Rails application, you can simply call this directly which avoids the abort_if_pending_migrations check:
ActiveRecord::Tasks::DatabaseTasks.load_seed
See where seeds are actually called from within ActiveRecord:
https://github.com/rails/rails/blob/v6.0.3.2/activerecord/lib/active_record/railties/databases.rake#L331
and see the DatabaseTasks docs:
https://apidock.com/rails/v6.0.0/ActiveRecord/Tasks/DatabaseTasks
https://apidock.com/rails/v6.0.0/ActiveRecord/Tasks/DatabaseTasks/load_seed
New to Rails here. Couple of questions about migrations:
I created a migration that I no longer want. I want to remove it. Is the correct command simply rails destroy migration AddMyColumnToMyModel ?
Let's say I mistype that migration name that I want to destroy... Here's what happens when I attempt to destroy a migration that does not exist.
$ rails destroy migration Blah
invoke active_record
remove migration.rb
It says it's removing migration.rb... Is this a bad thing?
Sure, that's the right command. Just be careful: if you actually ran the unwanted migration by using rake db:migrate to commit the changes to your database, be sure to run this before anything else:
rake db:rollback
What that does is run the down method on your latest migration. It does absolutely the same thing as:
rake db:migrate:down VERSION=20130529014413
Where the version number corresponds to that of your latest migration. It can also take a STEP parameter in case you need to roll back a bunch of migrations instead of only one, like so:
rake db:rollback STEP=3
Of course, if you just generated your unwanted migration and never ran it, there's no need to roll anything back. You can use the command you posted or manually delete the corresponding file to get rid of it.
Source: http://guides.rubyonrails.org/migrations.html#rolling-back
Don't worry, that's not doing anything to your code.
I have seeded a row of data to my table by editing db/seed.rb file and executing rake db:seed command. Unknowingly, I put some wrong information in to that row. So I want to remove the previously added row of data. Is there any rake command for the same like rake db:rollback for rake db:migrate.
There are a couple of aspects to this:
1: You want to change the seed data when no other data is present in the database:
You should simply redo the rake db:seed after updating the seed.rb file. Make sure you have MyModel.delete_all before you try to add anything to that model.
2: You want to change the seed data, but there are other data added to the database
This is a bit harder. Often the simplest thing to do here is to manually change the data with either raw sql-statements, or with the use of tools like PhpPpAdmin, PhpMyAdmin etc.
Now, there is possiby one way to hack this together, and that would be to do some voodoo in the seed.rb file. So you could run rake db:seed deseed=true, then in your seed.rb:
if ENV['deseed']
#Do your deseeding action here
else
#Do your seeding here.
end
You could even get real crazy and do something like this:
deseed = ENV['desee']
#DANGER: Dirty hacks upcoming:
deseed? myModelCall = MyModel.method(:destroy_all): myModelCall = MyModel.method(:create)
myModelCall.call :user_id_or_whatevs => 23 #this creates or deletes a MyModel entity with the given parameters
#NOTE this might not work in all cases and I would not necessarily recommend doing this.
#<3uby
I had similar issues when I seeded my data. In fact, I ran the seed command twice and I couldn't find a way to revoke the second seed. However, I had to run rails db:reset command and then run the rails db:seed command again and that fixed the problem for me.
When I ran bundle exec rake db:test:prepare I got the following:
rake aborted!
Multiple migrations have the name CreateMicroposts
To check the status of my migration files, I ran
rake db:migrate:status
And got:
Status Migration ID Migration Name
------- --------------- -----------------
up 20120616205407 Create users
up 20120622103932 Add index to users email
up 20120622114559 Add password digest to users
up 20120628095820 Add remember token to users
up 20120704123654 Add admin to users
down 20120706103254 Create microposts
up 20120707073410 Create microposts
As you can see, I have two migration files with the exact same names and the exact same code in them. It's only their statuses differ, i.e. Up and Down.
What does Up and Down signify?
And which one can I delete, if I have to?
The problem is that you have two different migration files containing the header
class CreateMicroposts< ActiveRecord::Migration
rake db:migrate:status does not check the status of your migration files. It tells you what migrations will be applied if you run rake db:migrate. The up/down labels are pretty much self-explanatory: it tells you whether the migration will be applied via the up method or the down method. The up method is ran when you migrate and the down when you rollback a migration. You can make some further reading about Rails migrations here.
up is the method called when "evolving" (ie migrating to a new schema), while down is the method called when "regressing" (ie migrating to an older schema version, because one of your changes doesn't suit you). db:migrate calls up, db:rollback calls down. In recent versions of rails, there's change that handles both at the same time.
As for the deletion... I don't do activerecord much these days, but I think you're free to do whatever you want with your files. I don't think deleting a duplicate file will do any harm, and if it does.. Well, you use source control, right ? :)
My Environment -> Ruby 1.9.2 and Rails v3.0.5
I noted a strange pattern in rake db:reset. According to rails source code, rake db:reset will => db:drop, db:create and db:migrate. https://github.com/rails/rails/blob/v3.0.5/activerecord/lib/active_record/railties/databases.rake#L159
Setup: One of my migration files have Model.create statements to populate some data (Forgive me, I'm not the one who had put data-filling-code in those migrations :) ..)
Case 1: When I do the steps manually, i mean drop, create, and migrate, one by one - those statements fill data in the table.
Case 2: When I do just rake db:reset, schema is set properly. but the data is not entering the db. Does db:reset skip create/update statements.. I have tried this several times to make sure that I have no faults in the steps I do. I still get this behavior.
what is going wrong here... ?
I think you're reading the wrong line in the source. As I read it:
db:migrate:reset # => [:drop, :create, :migrate]
db:reset # => [:drop, :setup]
So db:reset just create the tables and sets the migrations as if they had been run, without actually running them. db:migrate:reset actually runs each migration.
I had the same problem before but I was running 3.0.3, and it turns out, somehow I manage to mess up the migrations by change the migrations files and not running the migrations(forgot about it or something)...I'll start by checking those files