I'm a SQL pro and a rails newbie.
I'm having trouble understanding how best to use the rails database abstraction. Things I can do from a SQL command line in seconds seems overtly laborious in rails.
For example:
I generated a scaffold with several models and then tried to generate migrations to add associates to those models.
The generated migrations used 'create table' which won't work because the table already exists.
So I can either drop and recreate the table or use SQL 'ALTER TABLE' statements in the migration which makes me think I should have just created the database model by hand in the first place.
What are the benefits of using the rails data abstraction as apposed to doing the SQL with modeling tools and just using schema:dump and schema:load?
Well there are many reasons why you want to use migrations over than just writing your create table and ALTER TABLE in the console.
1.When I add a new table to column to a table there is a record that it happened and the rest of the developers on the team will know about it on the next commit with out having to send out email with complicated instructions to the ones that are not SQL pro
2.When you use a migration and you want to change databases from MySql to Postgres or anything else all you have to do is change the connection script
you can rollback your changes
Example:
class AddSsl < ActiveRecord::Migration
def up
add_column :accounts, :ssl_enabled, :boolean, default: true
end
def down
remove_column :accounts, :ssl_enabled
end
end
there are much more that you can do with migrations.
I recommenced looking at
http://api.rubyonrails.org/classes/ActiveRecord/Migration.html
Related
I want to delete a table in my rails app but i cannot use rollback, because i created this table a long time ago, and i have a LOT of other tables created since that one.
How is supposed to be named a drop table migration file and is there a way to genrate it with rails generate?
Create one more migration to drop the table. The class should have the method
def self.up
drop_table :table_name
end
Be careful as you will not be able to rollback to get all the data you will lose while dropping the table.
I'm looking for some advise on the following:
You have an app live with customers and real data
While developing new features, you need to add a column to lets say the projects table
This new column is a UID of some type which is generating by the model using a before_save
This all works fine for new projects moving forward. But all existing projects are nil for that column and everything breaks.
How do you handle his in the Rails world?
Thanks
You could simply create a rake task that pulls in all projects without a UID and and one to each project.
After you run the migration run the task. All of your projects should now have a UID.
I think this should be handled within the migration script, rather than a Rake task.
If I understand correctly, it'll only ever need to be performed once, at the time the column is added to historical records. In my mind, a migration script shouldn't leave the app with a broken data set. Migrations are designed for more than just schema changes.
Here's an example:
def self.up
change_table :projects do |t|
t.integer 'new_column'
end
Project.reset_column_information
Project.all.each do |project|
project.new_column = some_value
project.save
end
end
The reset_column_information method makes Rails aware of the new column you just added.
Simple question that used to puzzle me about Rails:
Is it possible to describe a Model's structure from within the model rb file?
From what I understand a model's data structure is kept within the migration, and the model.rb file is supposed to contain only the business logic.
Why is it so? Why does it make more sense to migrate the database with a rake task than to extract it from the class?
The reason migrations are stored separately is so that you can version your database. This would be unwieldy if done inline in the model.
Other ORMs (like DataMapper) do store the schema in the model definition. I think it's really convenient to be able to see model attributes right there, but it is unfortunate to not have the history of your database structure.
What I really wish is that running the migrations would just insert some comments at the top of the model file detailing the schema. That should be a simple hack.
Migrations do not simply show the state of the database schema.
They define the transitions from one state to another.
In a comment to cam's post, you said having the schema in the model would do the same thing, if you had the model's source stored in a VCS, you could look up the previous versions of the schema.
Here is why that is not equivalent to migrations:
Schema Version 1
string :name
string :password
string :token
Schema Version 2
string :username
string :displayname
string :password
string :token
So, what did I do here? What happened to "name"? Did I rename it to username? Or maybe I renamed it to displayname? Or did I drop it entirely?
You don't know. There's no way to tell. You only see the "before" and "after" of the schema. You don't see the transition.
Let's instead look at what I really did with this migration:
class UpdateNameFields < ActiveRecord::Migration
def self.up
rename_column :users, :name, :username
add_column :users, :displayname
User.update_all("displayname = username")
end
def self.down
remove_column :users, :displayname
rename_column :users, :username, :name
end
end
See, I had been using "name" for usernames. But you wouldn't be able to tell that without the migration here. Plus, in an effort to not have my new displayname column be blank on all my existing records, I have seeded it with everyone's existing usernames. This lets me gently introduce this new feature - I can use it and know that existing records aren't going to just see a blank field.
Note that this is a trivial example. Because it was so trivial, you could take a guess that it was one of a couple possible options. But had it been a much more complex transition, you simply would not know.
Transitions from one schema to another can involve a more than just adding/deleting/renaming columns. I gave a little example above in my User.update_all. Whatever code you might need to execute to migrate data to the new schema, you can put in the migration.
When people say migrations are about "versioning the database", they don't just mean versioning the snapshot of the schema. They mean the ability to move between those schema states, and triggering all of the actions involved in going from one state to another.
When is it acceptable to raise an ActiveRecord::IrreversibleMigration exception in the self.down method of a migration? When should you take the effort to actually implement the reverse of the migration?
If you are dealing with production-grade systems then yes, it is very bad. If it is your own pet project, then anything is allowed (if nothing else, it will be a learning experience :) though chances are that sooner rather than later, even in a pet project, you will find yourself having put a cross over a reverse migration only to have to undo that migration a few days later, be it via rake or manually.)
In a production scenario, you should always make the effort to write and test a reversible migration in the eventuality that you go through it in production, then discover a bug which forces you to roll back (code and schema) to some previous revision (pending some non-trivial fix -- and an otherwise unusable production system.)
Reverse migrations range from mostly trivial (removing columns or tables that were added during migration, and/or changing column types, etc.) to somewhat more involved (execute of JOINed INSERTs or UPDATEs), but nothing is so complex as to justify "sweeping it under the rug". If nothing else, forcing yourself to think of ways to achieve reverse migrations can give you new insight into the very problem that your forward migration is fixing.
You might occasionally run into a situation where a forward migration removes a feature, resulting in data being discarded from the database. For obvious reasons, the reverse migration cannot resuscitate discarded data. Although one could, in such cases, recommend having the forward migration automatically save the data or keep it around in the eventuality of rollback as an alternative to outright failure (save to yml, copy/move to a special table, etc.), you don't have to, as the time required to test such an automated procedure could exceed the time required to restore the data manually (should the need arise.) But even in such cases, instead of just failing, you can always make the reverse migration conditionally and temporarily fail pending some user action (i.e. test for the existence of some required table that has to be restored manually; if missing, output "I have failed because I cannot recreate table XYZ from nothingness; manually restore table XYZ from backup then run me again, and I will not fail you!")
If you are destroying data, you can make a backup of it first.
e.g.
def self.up
# create a backup table before destroying data
execute %Q[create table backup_users select * from users]
remove_column :users, :timezone
end
def self.down
add_column :users, :timezone, :string
execute %Q[update users U left join backup_users B on (B.id=U.id) set U.timezone = B.timezone]
execute %Q[drop table backup_users]
end
In a production scenario, you should always make the effort to write and test a reversible migration in the eventuality that you go through it in production, then discover a bug which forces you to roll back (code and schema) to some previous revision (pending some non-trivial fix -- and an otherwise unusable production system.)
Having a reversible migration is fine for development and staging, but assuming well tested code it should be extremely rare that you would ever want to migrate down in production. I build into my migrations an automatic IrreversibleMigration in production mode. If I really needed to reverse a change, I could use another "up" migration or remove the exception. That seems sketchy though. Any bug that would cause a scenario this dire is a sign that the QA process is seriously screwed up.
Feeling like you need an irreversible migration is probably a sign you've got bigger problems looming. Maybe some specifics would help?
As for your second question: I always take the 'effort' to write the reverse of migrations. Of course, I don't actually write the .down, TextMate inserts it automatically when creating the .up.
Reversible Data Migration makes it easy to create reversable data migrations using yaml files.
class RemoveStateFromProduct < ActiveRecord::Migration
def self.up
backup_data = []
Product.all.each do |product|
backup_data << {:id => product.id, :state => product.state}
end
backup backup_data
remove_column :products, :state
end
def self.down
add_column :products, :state, :string
restore Product
end
end
IIRC, you'll have the IrreversibleMigration when changing a datatype in the migration.
I think another situation when it's ok is when you have a consolidated migration. In that case a "down" doesn't really make sense, as it would drop all the tables (except tables added after the consolidation). That's probably not what you'd want.
I need to make changes to an in-use production database. Just adding a few columns. I've made the changes to the dev database with migrations. What is the best way to update the production database while preserving the existing data and not disrupting operation too much?
It's MYSQL and I will be needing to add data to the columns as well for already existing records. One column can have a default value (it's boolean) but the other is a timestamp and should have an arbitrary backdated value. The row counts are not huge.
So if I use migrations how do I add data and how do I get it to just do the two (or three - I add data -latest migrations on the production db when it wasn't initially built via migrations (I believe they used the schema instead)?
I always follow this procedure:
Dump prod database with mysqldump command
Populate dev / test database with dump using mysql command
Run migrations in dev / test
Check migration worked
Dump prod database with mysqldump command (as it may have changed) keeping backup on server
Run migrations on prod (using capristano)
Test migration has worked on prod
Drink beer (while watching error logs)
It sounds like you're in a state where the production db schema doesn't exactly match what you're using in dev (although it's not totally clear). I would draw a line in the sand, and get that prod db in a better state. Essentially what you want to do is make sure that the prod db has a "schema_info" table that lists any migrations that you >don't< ever want to run in production. Then you can add migrations to your hearts content and they'll work against the production db.
Once you've done that you can write migrations that add schema changes or add data, but one thing you need to be really careful about is that if you add data using a migration, you must define the model within the migration itself, like this:
class AddSomeColumnsToUserTable < ActiveRecord::Migration
class User < ActiveRecord::Base; end
def self.up
add_column :users, :super_cool, :boolean, :default => :false
u = User.find_by_login('cameron')
u.super_cool = true
u.save
end
def self.down
remove_column :users, :super_cool
end
end
The reason for this is that in the future, you might remove the model altogether, during some refactoring or other. If you don't define the user class on line "User.find_by_login..." the migration will throw an exception which is a big pain.
Is there a reason you are not using the same migrations you used in your dev environment?
Adding a column with add_column in a migration should be non-destructive: it will generate a "ALTER TABLE" statement. If you know what you're going to put into the columns once created, you can fill in the values within the migration (you may choose a less time-consuming alternative if the row counts are large).
Removing or altering the definition of a column is, I think, platform-dependent: some will allow deletion of a column in place, others will perform a rename-create-select-drop sequence of commands.
To get more specific, we need more information: what kind of migration are you looking at, what platform are you running on, do you need to set values as part of the migration? Stuff like that would help a lot - just edit the question, which will push it back up the list.