I was aware of the changes going up and down with the version but not of this. Nice screencast, as always :)
Keep it up
What if I want to rollback some migrations?Let's say I have
create_users
create_products
create_categories
and I want to roll back until the product migration.Before this changeset,I could easily do this by typing rake db:migrate VERSION=X
Where version number? I kid, the grammar nazi attacks. I think that is "their version number"
if i update rails to 2.1 and then run migrations on an existing project in 2.0 does this mean that i would have to rename all my db/migrate files? and since my migrations have already been run in my 2.0 project, the schema_migrations (which don't exist yet) also don't have the proper entries for tables that already exist... is there a rake task that will ready an existing rails 2.0 project to co-exist with 2.1 migrations?
@Alex, you can still do that, you'll just have to use the full timestamp as the specified version. What I usually do is run "rake db:rollback" as many times as needed.
@Don, thanks, fixed. :)
@sthapit, while I haven't fully tested this, I believe everything will just work. You don't have to rename anything, it will just use the existing version numbers. Also when you first run the migration I'm assuming it will properly generate the schema_migrations table and fill it will the existing entries. Someone please correct me if I'm wrong.
In Rails 2.1 you can now do migrations much more easier by the rake-tasks db:migrate:up, db:migrate:down, ...
this enables you to specify the version-number (now the timestamp) to migrate a single migration up and down :)
so if you want to delete migration number 15 out of 30 you don't have to rollback all the way or write a new one (31) which revert number 15.
example:
rake db:migrate:up VERSION=20080402122523
found in:
http://ryandaigle.com/articles/2008/4/2/what-s-new-in-edge-rails-utc-based-migration-versioning
lg
@QuBit thanks for bringing this up! I was originally planning on mentioning it in this episode, but I couldn't think of a good scenario on when I'd want to do this.
If I need to remove an older migration, I much prefer creating a new migration which does this, that way it applies on deployment and for any other developers who may have the code.
Does anyone know the reasoning behind the db:migrate:up/down additions?
I'm not sure what the original reason was for this, but it's made my life a lot easier when dealing with big datasets. For example I have an app with a cache of geographic information with 100K records which is a pain to constantly restore. While I'm still in development I frequently make changes to earlier migrations and just re-run them on my local, leaving the big dataset intact, without cluttering up the app with pre-production migrations.
I used to do this by going to the console and instantiating the class directly, but that was a pain.
So erm..... how do you actually create a timestamped migrations file? I always did File > New and gave it a name myself.
So erm... $ script/generate migration update_users of course.
Thanks for this update. I would like to point out an issue that arises when you freeze the current date for "today" in your application.
In general, the new version setting is fine because I doubt anyone was previously up to version 20080605122345. This is NOT ok if you're setting the time and date of "right now" in the application. For example, the date of present time is set to midnight, May 15th, 2007 in an app i'm working on (obviously development only). This means my new migrations (ALL of them) are given the same version of 20070515000000_.... and this is bad news.
I just manually rename them and all is well. An untrained developer picking up someone else's project might not notice this right away.
I see no benefits from the new naming convention.
How can I migrate to VERSION?
The way it was:
rake db:migrate VERSION=1
The way it is?
1) with either plain or timestamped version numbers, the migrations just care about the order of the numbers..
It seems to be just a difference in how the number is generated.
2) you can disable timestamped migrations by putting this in your environment.rb file:
config.active_record.timestamped_migrations = false
3) If you have a project with a lot of developers who do schema changes, the timestamps will help.
(Meetings will help more! ;-) )
On the other hand you might have a project where you have a larger schema & dependency change,
and you might need to renumber all your migrations to allow a smooth "rake migrate" (up and down).
In this case you'd have to either "make up" fake timestamps for your migrations, or better: go back
to plain version numbers for the migrations.
@Ryan Bates
I think you can use it to limit the number of migrations. So, if you need to change something in an existing migration, just edit it, migrate:down VERSION=xxx, migrate:up VERSION=xxx.
I like this because it keeps me from having a bunch of tiny migrations with column renames.
A little like gist vs pastie.
An example of a rake db:migrate:up would be if you are moving from one db to another (ie sqlserver version XYZ.1 to sqlserver version XYZ.2) and have a bunch of imported data (static data) as a migration.
So: rake db:schema:dump on sqlserverXYZ.1, goto sqlserverXYZ.2, do a rake db:schema:load
Then you would rake db:migrate:up VERSION=XXXXXXXXX (your import migrations).
That way - you don't have to worry about sqlserver version dependencies with migrations that may fail due to version incompatablity - but can still use the migration scripts needed to load your static data
Is there a simple way to move up or down by a single migration? I need to go through about 50 migrations, in order, examining the db after each (and looking at the migration output/errors.)
Moving along by typing out each version number is a pain. It would be great if I could do something like:
rake db:migrate VERSION=NEXT
Thanks...
finally i've understood the process of functioning of such migrations.. thanx guys.!
Ryan - I hope you can help me with this. We had a mess with our production database. We just upgraded from Rails 1.2 to 2.3.2, so we had a schema_info table, no schema_migrations table. When we ran command for migrations, instead of it recognizing via the old schema_info table that we were at migration 64, it just started running all the migrations starting with 1. I don't know why the automatic table replacement didn't occur, but now I need to figure out how to clean it up. Should I just delete the schema_info table and manually create/populate a schema_migrations table?
as per comment #14 that says:
you can disable timestamped migrations by putting this in your environment.rb file:
config.active_record.timestamped_migrations = false
------
I tried this, but it still uses the timestamp version. Any ideas why?
It's great to see an article like this. www.mbtselling.com www.jerseystown.com www.dunkjordan.com www.airmaxsupplier.com www.ghdbeautyhair.com
It seems the fights and arguments are no longer about helping those in need,
I really impressed by your post. Thank you for this great information, you write very well which i like very much.
Good job! welcome to visit http://www.eleczilla.com/
efox-shop the best place to buy dual SIM dual standby phone. The efox-shop service is good, and the full range, such as Sciphones i68 ciphone c6 Ciphone cect handy Sciphones cect handys hiphone HIPHONE 4 pinphone 3gs welcome to purchase http://www.efox-shop.com <a href="http://www.efox-shop.com">Sciphones i68 ciphone c6 Ciphone cect handy Sciphones cect handys hiphone HIPHONE 4 pinphone 3gs
Oh dear, I hope that one day, I'll finally become a serious rails developer and write everything on my own. But for now, thanks for help!
eFox-shop.com puts quality at the top of business plan. Our Quality Control team carries out various testing processes to ensure only quality products are sold on the web. No counterfeits or reimbursed items would appear on our selling lists.
http://www.efox-shop.com/
we provide our buyers with an efficient and manageable procurement process covering every phase of the international supply chain and
streamlining trade channels. Also welcome wholesaling, feedback now!
I was very pleased to find this site.I wanted to thank you for this great read!! I definitely enjoying every little bit of it and I have you bookmarked to check out new stuff you post.
Thanks, very informative and at the same time easy to understand
Ha, that’s actually a really good suggestion. Thanks so much for this!
This is all very new to me and this article really opened my eyes.Thanks for sharing with us your wisdom.
Just to echo what others have said, after multiple searches across the web this solved my check_box problem in five minutes. Thanks so much!
Good job! very good cord.This is all very new to me and this article really opened my eyes. thank you
Nice blog. The content of your blog is exactly wonderful, and your blog template is Simple generous. So good
I really appreciate what you post. If only i could think of a plugin to actually write. I will instantly grab your rss feed to stay informed of any updates. thank you very much!!
Thanks for sharing your article. I really enjoyed it. I put a link to my site to here so other people can read it. My readers have about the same interets
Discount Wholesale Electronics, Wholesale Cell Phones, Electronic Gadgets and More from the Best Dropship Wholesaler
Also when you first run the migration I'm assuming it will properly generate the schema_migrations table and fill it will the existing entries.






