Most of the time when you commit a migration, you'll want to run that migration against the code base you have when you check that migration is. To make this simpler to do, all you have to do is call use_git and gitty migrations with automatically find that revision for you.
Here's an updated example on how to use gitty migrations
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
|
class ResetAllAccountTypes < ActiveRecord::Migration
use_git
# or
# use_git :revision => "42ca6c6de8cbd6591dcada7437c97"
# or
# use_git :revision => "v2.0"
def self.up
add_column :user, :account, :integer, :null => false
User.find(:all).each do |user|
user.account = case user.account_type
when "Free" : Account::Types::Free
when "Paid" : Account::Types::Paid
else Account::Types::Unknown
end
end
remove_column :user, :account_type
end
def self.down
...
end
end |
Download it from GitHub
0 comments
Migrations make it super easy to work with your database in Rails, with only a few small problem that I've run across.
Certain migrations rely on specific changelists
Most of the time, this is because you're dealing with a legacy database that you are trying to clean up and you are moving data around. You want everyone to get the changes, but don't want to rely on people running a rake task at a certain revision to implement the changes. To get around this we sometimes redefine a class in the migration to override the newer, updated class of the same name in our application. But what if we didn't have to do this, what if we could just tell the migration what revision or changelist the migration should run against and let it run. This is where gitty migrations would come in.
Here's how it's done. (this example was just done for the purpose of showing how the plugin works)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
|
class ResetAllAccountTypes < ActiveRecord::Migration
use_git_revision "42ca6c6de8cbd6591dcada7437c97000839e8074"
# or if you've used git-tag to tag your revision
# use_git_revision "v2.0"
def self.up
add_column :user, :account, :integer, :null => false
User.find(:all).each do |user|
user.account = case user.account_type
when "Free" : Account::Types::Free
when "Paid" : Account::Types::Paid
else Account::Types::Unknown
end
end
remove_column :user, :account_type
end
def self.down
...
end
end |
Now whenever a developer runs this migration, it will check out that revision of git, run the migration against it, and then change your git repository back to where it was. If in the future you decide to use an account type table instead of an enum and change all your code, this migration will still work.
Download it from GitHub
TODO
- If you don't set a revision have it automatically use the revision you checked the migration in on.
Thoughts or comments? Have a better way of dealing with this. Let me know.
2 comments
