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
Related
I accidentally deleted table "results" from schema with this command in rails console:
ActiveRecord::Migration.drop_table(:results)
I tried but not working
rake db:migrate:up VERSION=201608021358
How can I take it back? I just want the structure not the data
Please help!
You dropped the table directly without migration so there is no neat way.
Comment everything from down method from 201608021358_xxxx.rb assuming this migration is create_results
Reason for commenting the code is "Your migration is still UP as you haven't done it through migration" and if you UP it it will not do anything while DOWN will give you error saying results table doesn't exist
rake db:migrate:down VERSION=201608021358
rake db:migrate:up VERSION=201608021358
that will solve the issue
I created an integer for a phone number, and then learned that it is better to consider it as a string due to it's size.
I decided then to change directly the migration and apply db:reset instead of adding a new migration since the project is only on my computer at this moment. Db:reset worked but it doesn't seem that my database changed.
It raised a lot of questions :
Is there a command to analyse a database and identify the types of its columns ?
Does db:reset allow to modify a migration, like after rolling back a migration ?
Even though it isn't preferable, what are the conditions to modify directly a migration ?
The db:reset task resets the database by dropping the database and then loading schema.rb - it does not run migrations again. If you dropped the database, then created it and ran db:migrate then you should get the desired outcome
Change the field as string in migration, then run the commands:-
rake db:drop
rake db:create
rake db:migrate
And it will change the field type from integer to string.
I have run into a very strange problem. I have a task which resets my database as so:
task :reset => [:drop, :create, :migrate, :seed]
The problem is, I am receiving errors when seeding because of missing columns which are added in late migration files. One example:
undefined method new_attr= for User
Yet this attribute is already added in a migration. The strange part is, I receive no errors if I run the above tasks separately. Can anybody shed some light? Surely these tasks cannot be run asynchronously.
Another way to avoid errors is to amend my earlier migrations create_ with the new attributes. Then running :reset doesn't trigger errors for those attributes.
The migrations are clearly fine as I can run the above tasks separately, just not bundled under a single task.
maybe you want to make your reset task more explicit?
namespace :db_tasks do
desc "Rebuild development db"
task :rebuild_database, [] => :environment do
raise "Only run in development or staging" if Rails.env.production?
Rake::Task['db:drop'].execute
Rake::Task['db:create'].execute
Rake::Task['db:migrate'].execute
Rake::Task['db:seed'].execute
Rake::Task['db:test:prepare'].execute
end
end
Probably your problem is already solved using this:
rake db:reset
The rake db:reset task will drop the database, recreate it and load the current schema into it.
Have you tried with namespace?
task :reset => [db:drop, db:create, db:migrate, db:seed]
If these rake tasks are executed in the production mode,
model attributes are cached. Even though migrations work perfect, it wont apply to the cached.
This will break your succeeding seed as newly added columns will be missing in the cache.
A possible solution is to reload your rails environment before seeding.
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.
The command rake db:migrate will apply all relevant new migrations to a database and will list in the output the migrations that were applied.
I'd like to know in advance what migrations will be applied so as to note down a list of the changes that are expected in a production environment.
Is there an option I can use in conjunction to rake db:migrate that will show me what changes will be applied without actually applying them?
Does rake db:migrate:status (rails 3+ only) fit the bill?
I guess here's the answer: Show pending migrations in rails .
If you are deploying with capistarno, you could add a task similar to this: http://gem-session.com/2010/08/warn-of-pending-migrations-when-deploying-with-capistrano .