Let's say I used the following command to create a "User" model:
script/generate model User username:string
This creates the user.rb file along with the migration rb file to create the Users table. Now, I want to add an email column to my User model. What's the best way to do that? Do I do it manually and write the migration file by hand or is there a shortcut for doing it? If I write the migration by hand, do I have to name it the same way as the previous migration script (with a timestamp in front) to guarantee that it runs after the previous migration?
Don't worry about the timestamp. It will be generated automatically.
You can do a
rails generate migration add_email_to_user email:string
This would automatically create a migration file which would look like this:
class AddEmailToUser < ActiveRecord::Migration
def self.up
add_column :email, :string
end
def self.down
remove_column :email
end
end
the file would have the timestamp in the format YYYYMMDDHHMMSS (For Rails 2.1 and above) appended in front of the filename.
The Guide has information about generating migrations. If you use the rails generator, it will create correctly named files:
ruby script/generate migration AddEmailToUser email:string
Well you can do two things:
1) If you haven't deployed this anywhere yet, or you don't mind dumping the db and running your migrations again, then modify the file. Remove the tables from your db, and run db:migrate. Easy to do this in development.
2) If this app is in production, or you don't want to drop all your tables. Then create a new migration file. Then in this new migration add/modify/drop the column. Then run db:migrate and the new changes will take effect in your table. This is the best practice.
As for naming your migration, timestamps are used because rails will create a table that keeps track of the latest migrations ran. For this, it is better to use the timestamps. But if you choose, you can use your own convention instead of timestamps. Maybe name them 001_migration.rb, 002_migration.rb, etc.
Hope that helps.
Related
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.
As you will see, I'm pretty new to Rails.
I am trying to follow section 3.3.2 in the RailsGuides on Active Record Associations and it says there that when defining a many to many relationship, besides adding the has_and_belongs_to_many directive to the model, you "need to explicitly create the joining table".
It then gives an example of the content of the migration file:
class CreateAssembliesPartsJoinTable < ActiveRecord::Migration
def change
create_table :assemblies_parts, id: false do |t|
t.integer :assembly_id
t.integer :part_id
end
end
end
My question is: what name should I give to that file? I see that the files generated by the rails g ... command are all in the ..db\migrate folder and have a kind of timestamp at the beginning of the file. Can I use any name? I'm afraid to test and mess up the whole thing. I'm used to MS-SQL and being able to see the tables, add/modify columns, etc.
Side question: there are a few files already there, from previous migrations. How does rails know which ones were already run? And what about running them afterwards when deploying to, say, Heroku?
You can give any name to your migrations. Preferably something self explanatory like create_table_something. You can generate a migration by doing
rails generate migration create_assemblies_parts_joins_table
This will generate a file like below in db/migrate folder
<timestamp>_create_assemblies_parts_joins_table
Rails keeps track of already run migrations in scheme_migrations table. It stores the timestamp of all the migrations that are already run
UPDATE:
You can change the table name to whatever you want in the migration file. Table will be created with the name you give in the following line
create_table :assemblies_parts, id: false do |t|
assemblies_parts will be the table name.
You should not build the file from scratch yourself. As #Vimsha has already said - you can run a rails migration to create a join table migration for you.
The rails standard naming for a join table is to take the two names of the models you are joining, and write them in alphabetical order and pluralised.
eg if your models are "user" and "post", it would be "posts_users", but if it were "post" and "comment" it would be "comments_posts"
I am pretty new to Ruby on Rails, and I was wondering if there was a way to edit the database schema for a model.
For example, I have the Subscriber model in my application -- the way I created it was by using rails generate scaffold Subscriber email:string
But now, I want a name in the subscriber model as well. Is there any easy way to do this? I have put a lot of code in my current controllers and views, so I don't necessarily want to destroy the scaffold, but I would like to edit the model.
Thanks in advance,
hwrd
P.S. I am using Ruby on Rails 3
An ActiveRecord Model inspects the table it represents. You don't actually need to change your model just to add a new field (unless you want to add validations, etc).
What you want to do is make a new migration and then migrate your database up:
rails g migration AddNameToSubscribers name:string
rake db:migrate
Then you can start referencing the name field in your controllers and views.
(This generator command might seem a little magical, but the rails generator recognizes this format and will generate the appropriate add_column and remove_column code. See the Rails migration guide for further reading.)
If you mean changing the database schema of your model, you'll want to use migrations.
You'll do things like
add_column :city, :string
remove_column :boo
http://guides.rubyonrails.org/migrations.html
If you do only mean finding models and updating the data inside each instance, go with #apneadiving's answer.
I am using rails 2.3.8. I had created a migration for a table called user which currently has plenty of records.
Now the requirement is to add a new column to it.
I had to create a new migration file since rollback would delete the other table data. But adding a new migration did not work.
def self.up
add_column "users", "xyz", :string, :default => "0"
end
What might be the reason?
is it because the data is already loaded?
is it something to do with caching?
Thanks in advance.
Following up on #elmt's comment, you should create migrations using the command in your rails root directory:
script/generate migration <your_migration_name>
So in your case that would be something like this:
script/generate migration add_xyz_to_users
This will create a filename of the form db/migrate/20101122183814_add_xyz_to_users.rb. That's where you should add your migration. If the filename is not named correctly, the migration will not run.
Ben pointed out correctly. That might be due to older migration version number. But can you tell which type of error are you facing? And is it during running migration or what?
I am a Rails beginner and trying to understand how rails migration works.
I have created a scaffold like:
script/generate scaffold Item col1:string col2:text
rake db:migrate
I would like to add another col4 using migration:
I created a migration as follows:
class AddCol4 < ActiveRecord::Migration
def self.up
add_column :items, :col4, :numeric
Item.reset_column_information
end
def self.down
remove_column :items, :col4
end
end
When I run rake db:migrate the new column gets added. However the view is out of sync.
Am I supposed to manually add the new column to the view? Is there a way to auto-regenerate the model/view using the new table columns?
Sorry, it is a basic question but from my experience with other frameworks, it should have been automatic.
The rails guide on migration does not make this obvious regarding how the synchronization is supposed to work after you perform a migration.
Unfortunately you will need to modify the view manually. The view is created by running the script/generate scaffold command. Migrations only change the database. Technically, you can rerun the scaffold command and have it regenerate the view. It will ask you if you want to overwrite the previous file, however, if you go this route, you will still need to specify ALL of the columns that you want. You can't simply add some here and there.
If you are early in development, then you might take this route. Simply run
script/destroy scaffold Item
and then rerun
script generate scaffold Item col1:string col2 string col3:numeric
There are some dynamic scaffolding extensions available such as ActiveScaffold if you are creating something that only a few users will see, but I would recommend doing the HTML yourself as it will always come out the way you want.
I can't seem to find any of the other dynamic scaffolding plugins. There used to be quite a few...