I originally had a migration called CreateUsers that had a table already.
Due to my stupidity, i thought i had to do a rails generate migration in order to add indexes to the table. When i did a migration it was this:
rails generate migration CreateUsers years:integer
So it creates a migration with the timestamp and so on, and i tried deleting using this
rails d migration migration_filename
Its giving me some error regarding this
/Users/giowong/.rvm/gems/ruby-2.0.0-p353/gems/activerecord-4.0.2/lib/rails/generators/active_record/migration/migration_generator.rb:57:in `validate_file_name!': Illegal name for migration file: 20140219230444_create_create_users.rb (ActiveRecord::IllegalMigrationNameError)
In the schema.rb table stll exists
should i manually delete both?
You don't want to run rails d against the filename, but against the migration name you had in your generate.
Try: rails d migration CreateUsers
In order to drop the table, you'll want to rollback your migration as well:
rake db:rollback STEP=1
STEP=1 assumes this was the last migration run. You also may need to prepend bundle exec if you're using bundler in your app.
Related
I currently have a migration and I simply want to add a couple more values to this migration such as to_limit and from_limit along with their default values (5&10). How should i do this?
class AddUserToCompany < ActiveRecord::Migration
def change
add_column :companies, :user, :jsonb, default: {"to_dist"=>50, "from_dist"=>70, "trs_one"=>100, "trs_two"=>120}
end
end
I added some changes which also requires "to_limit"=>5 and "from_limit"=>10. Please suggest on how to add a new migrate file and add the changes.
Rails version - 4.2.11
This is my first time working with a rails application. So i am really confused on how to proceed with this.
1.If this changes are in progress (not already used by other) then you can rollback this migration by command
rollback last migration
rake db:rollback STEP=1
In order to rollback ONLY ONE specific migration
rake db:migrate:down VERSION=20220905201547
and after applying changes, run rake db:migrate
If migration was created earlier then you can create new migration to apply your changes
generate new migration by command
rails generate migration nameOfMigration
I hope this helps
I generated a new migration using command,
rails g migration add_stdf_to_sds blahblah:string
I have not used rake:db migrate till now and I don't want to use it because I don't want this migration to happen, how can I delete my generated migration?
I know about rollback, but I haven't used db:migrate till now so it won't work. (I guess).
rails d migration add_stdf_to_sds
In general 'rails d' which stands for 'rails destroy' is a great way to undo any command that a generator has performed.
rails g migration adds a file in db/migrations that starts with a timestamp. Delete that file from the filesystem.
Good morning everyone,
I am trying to complete the calender app from Codeacademy, and I need to complete the following steps.
Open the migration file in db/migrate/ for the days table, and add the following columns:
a datetime column called date
Open the migration file in db/migrate/ for the days table, and add the following columns:
a datetime column called date
Open the migration file in db/migrate/ for events tracks table, and add the following columns:
a string column called name
a datetime column called from
a datetime column called to
a string column called location
a references column to the Day model
So far, I have added it manually to the migration files like so:
class CreateDays < ActiveRecord::Migration
def change
create_table :days do |t|
t.datetime :date
t.timestamps
end
end
end
class CreateEvents < ActiveRecord::Migration
def change
create_table :events do |t|
t.string :name
t.datetime :from
t.datetime :to
t.string :location
t.timestamps
#Not sure how to add references column????
end
end
end
However, I am running into an error when I run rake db:migrate, I get no output. Is there supposed to be an output? I have run rake db:migrate --trace and here is the output:
A migration file is like a script which changes your database in some way. It does not store the state of your database.
It will not do anything unless you run it: your database has a special table to keep track of which ones have been run already, called schema_migrations. When you do rake db:migrate you run all scripts in that folder which haven't been run already, according to that table.
So, if you run a script, then change it, then do db:migrate, it won't run it again because it thinks it's been run already. If it did run it again, it would likely blow up because it would be trying to add lots of columns that already exist.
If you define a table in a migration, then later want to add more columns, you can either roll the migration back (which will drop the table), then run it again with the added columns, or write a new migration which just adds the required new columns. The latter approach is usually best.
Whenever you run rake db:migrate,it runs all the pending migrations using the timestamp which every migration file has ..such as YYYYMMDDHHMMSS_create_products.rb.
Any file which has a migrations greater than the previously run migration timestamp will be picked up during rake db:migrate and then checked whether the changes are present in the db.
For example :
For a migration file 20080906120001_add_details_to_products.rb...if you have ran it then all the changes will be added in the db.if you edit it and then run it again then it won't be picked up as timestamp of migration should be grater then previously ran file,which is not.
You can manually change the migrations by editing few numbers so that it gets picked up again without creating a new file.
I would recommend create a new one as they are way to maintain and are each migration should be unique.
I assume that you have ran the migrations before. So there is a table named schema_migrations where it stores the migration which has already ran so you cannot re run them. The best way to add new columns to an existing table is to create a new migration like this:
rails g migration add_some_columns_to_events name:string
and name the other columns. And still if you need to do it using the existing migration then what you can do is:
rake db:migrate:down VERSION=<version_of_migration>
and then add up the columns in migration file and run:
rake db:migrate:up VERSION=<version_of_migration>
You can also rollback your last migration and re run the migration using:
rake db:rollback
Hope this helps.
You can only run a migration once - if you've already run the migration, you have two options:
You can roll back the migration with rake db:rollback, edit it, and then run it again with rake db:migrate, or
You can generate a new migration and put your changes in it. Then you can run the new migration with rake db:migrate.
So I've been going through a lot of rails tutorial, and I get that the default for adding a new column to a database is , for example,
rails generate migration add_reset_to_users reset_digest:string reset_sent_at:datetime
The above will add a reset_digest in the form of a string and reset_sent_at in the form of a date to the migration add_reset_to_users
My questions is what if I am clumsy one night at 4 AM and only call the following
rails generate migration add_reset_to_users reset_digest:string
I completely forgot about reset_sent_at but want to implement it the next morning. I made the mistake of adding the link directly to the db file, which was a huge mistake.
In this case what should I do? Do I simply call a new migration such as
rails generate migration add_reset_sent_to_users reset_sent_at:datetime
or is there an even better way?
first, if you have not run your migration, you can directly open the migration file, and add your column to the file, as
def change
add columns :table_name :column_name :column_type
end
In your case, you will modify the file as,
def change
add columns :users :reset_digest :string
add columns :users :reset_sent_at :datetime
end
and then run
rake db:migrate
if you have already ran your migration, and you have not run any other migration after that, you can undo it, by
rake db:rollback STEP=1
and then edit the migration file, and run your migration
Rule of thumb for migrations in Rails is that you always create a new migration file unless you have not already shared your code with others, i.e. pushed to remote repository, otherwise you can just change the old migration after running $ rake db:rollback and everything will be fine, and nobody will know about it, and won't affect other developers work(since it's still on your local repository).
So, I'd encourage you to create a new migration if you have already committed and pushed the code onto remote repository, and changing the old migration file again will hurt other developers productivity. In case of any confusion, always create a new migration:
rails generate migration add_reset_sent_to_users reset_sent_at:datetime
I think it depends what state your rails app is in.
If you were working on a production app then editing migrations is not advisable due to data loss and changes should be made with a new migration.
If your working locally in development then I would edit the migration directly and add the missing column and rerun your migration.
Don't be worried about editing you migrations, just remember to rake db:rollback the migration you are editing before making changes or you will encounter errors.
This is where changing your migration from:
def change
add_column('users', 'reset_digest', :string)
add_column('users', 'reset_sent_at', :datetime) # Would have to perform rollback before adding this line
end
to:
def up
add_column('users', 'reset_digest', :string)
add_column('users', 'reset_sent_at', :datetime) # Added after migration
**rake db:migrate
end
def down
remove_column('users', 'reset_digest', :string)
remove_column('users', 'reset_sent_at', :datetime) # Add this after rollback
**rake db:rollback
end
Allows you to make changes to your migrations before you rake db:rollback
This requires a bit more code but I find it easier when I'm building a new app and things are changing frequently.
I had a rails Model List.
I typed rails d model list in my terminal, resulting in this:
invoke active_record
remove db/migrate/20140116161958_create__lists.rb
remove app/models/list.rb
invoke rspec
remove spec/models/list_spec.rb
Then I typed rails g model list name:string size:integer which gave me this:
invoke active_record
create db/migrate/20140213155321_create_lists.rb
create app/models/list.rb
invoke rspec
create spec/models/list_spec.rb
Now, running rake db:migrate gives me this:
== CreateLists: migrating ===============================================
-- create_table(:lists)
rake aborted!
An error has occurred, this and all later migrations canceled:
PG::DuplicateTable: ERROR: relation "lists" already exists
The issue is that my table was not deleted from my DB. I can't roll back the migration that created that table, because it was destroyed when i ran rails d model list.
I could create a new migration and drop the table, but it would be placed after my migration created when I ran rails g model list..., so I assume it would error too.
Is my only choice to delete the model again, create a migration to drop the table, then recreate the model?
Also, in the future, how should one go about deleting and recreating a model? Roll back the migration prior to rails d model?
1>
before running rails d model list
run
$ rake db:migrate:down VERSION=20140116161958
will roll back the list file to remove table lists from database.
2>
but since u have already destroyed your model what u can do is delete table lists from rails database console. try this
$ rails dbconsole # from your app root path
and then type drop table lists;
3>
you can drop your table from rails console also
$rails console
Then just type:
ActiveRecord::Migration.drop_table(:lists)
4>
also u can create a migration file to drop your table :
$ rails generate migration DropListsTable
this will create an empty migration file now edit that file to look like:
class DropListsTable < ActiveRecord::Migration
def up
drop_table :lists
end
def down
raise ActiveRecord::IrreversibleMigration
end
end
then run $ rake db:migrate