How do I take, say, 20 of my older migrations and wrap them up into only a single one in order to clean up my directory? Thanks!
Not a good idea.
If you think 20 is a bad number I’d hate to see if you’d work on a big project (100+ migrations)
<rant> @Ryan, Do you ever stop to consider that people have very good reasons to do things that you might not do? I'm getting tired of seeing responses like "Gee I wouldn't do that" or "it's dumb to have that javascript turned off" or ... It'd be a lot more helpful, if you're that enlightened, if you would both explain how to do it AND SUGGEST why it is not considered a good idea.
That said, consider this. One site that I'm working on currently has 150+ migrations for about 120 tables. By your logic I'd be dumb to combine them. But it's quite possible that this app will be deployed both publicly (hosting for small customers) and privately (intranet for very large customers). I'm perfectly willing to keep creating migrations when necessary for the public side, but if I am doing a fresh install on a private site, what sense does it make to deploy the 20-30 migrations that are patched and overridden by later ones? Wouldn't a single, clean migration script serve those customers much better? </rant>
@Stedwick -- rake db:schema:dump should give you pretty much what
you're looking for. I'll let you discern from the previous comments
whether or not YOU think it's a good idea. 
Cheers.
From schema.rb
# Note that this schema.rb definition is the authoritative source for your database schema. If you need # to create the application database on another system, you should be using db:schema:load, not running # all the migrations from scratch. The latter is a flawed and unsustainable approach (the more migrations # you'll amass, the slower it'll run and the greater likelihood for issues).
In short, one reason you don't really need to consolidate migrations is because when deploying a application to a new server, you should really not use db:migrate because it can be slow, amass alot of redundancy, etc. Loading the latest schema is a much better practice.
so when starting from scratch use:
rake db:schema:load
over
rake db:migrate
(in most cases)
That said, I don't think consolidating old migrations is necessarily bad if its a personal project and no one else is relying on the migrations.
In fact, before a project is deployed for release, I tend to use:
Thanks, Andy! I knew there was some really easy way to do it. I
figure, I have all my old migrations in subversion anyway, just in
case, and when will I ever really need the first couple again? I'm
not going to roll back my entire application
Right. Schema loading is just for that purpose; migrating is just for incremental updates to the schema.
Even better, when you load schema.rb, it'll set the proper version so you can pick up from there using migrations just like it would if you were to do db:migrate.
This discrepancy is one of the biggest reasons you should never have data/logic in your migrations. If you do a schema:load, then you miss out on whatever seed data is in the migration. You should instead create something like rake db:bootstrap in lib/tasks or something.
--Jeremy
OK, so you wanted a “Why?”, here’s one.
I create many migration files, lets say 20, with matching models in them is one called “Person”. All of a sudden, I realise I don’t like having it called Person and I never liked the idea of having a persons table. If I had combined my twenty migrations into one big migrations file I am now going to have to go looking through this HUGE file for my persons table, delete the entry, and then continue on my merry way. If I had a single file I could delete that file easily because I know what to expect when looking for it and I know exactly where it’s going to be and I don’t have to dig through a hundred lines looking for it.
Having only one migration file (per table?) gives the impression that you are creating one migration file for each table, and when you want to change the schema, you change the migration and go back and rerun all the migrations?
If so this seems antithetical to the reason for migrations which is to keep the history of changes to the DB schema as a series of deltas.
OK, so you wanted a "Why?", here's one.
I create many migration files, lets say 20, with matching models in them is one called "Person". All of a sudden, I realise I don't like having it called Person and I never liked the idea of having a persons table. If I had combined my twenty migrations into one big migrations file I am now going to have to go looking through this HUGE file for my persons table, delete the entry, and then continue on my merry way. If I had a single file I could delete that file easily because I know what to expect when looking for it and I know exactly where it's going to be and I don't have to dig through a hundred lines looking for it.
Good, Ryan. But you miss my point. You have a tendency to present your opinion/preference as fact. My suggestion is instead to defer to the wisdom of the developer in his or her own context. As you post your recommendation, assume that the developer has the ability to discern whether or not your approach fits their context. You do that by giving the pro/con of your approach.
BTW, there is only one 'c' in Recommend. You might want to change that in your sig if you hope to attract would-be employers. Folks (like me) who are looking for Rails help see typos like that as an indicator of the level of attention you pay to details, especially when 'Recommend' can be copied and pasted from the WWR site.
Good luck.
BTW, there is only one ‘c’ in Recommend. You might want to change
that in your sig if you hope to attract would-be employers. Folks
(like me) who are looking for Rails help see typos like that as an
indicator of the level of attention you pay to details, especially
when ‘Recommend’ can be copied and pasted from the WWR site.
Good luck.
I’m currently happily employed, and “Reccommend” was a typo.
If this was code it would’ve thrown a syntax error, which I would’ve corrected right away, remembered my mistake and never do it again. Employers should not judge people’s programming skills by the amount of words they mistype in a sentence.
To be fair, If I was looking at a resume and it was filled with typos then that would be a cause for concern in my opinion. Not the typos themselves but the lack of respect and professionalism in that the person did not care to correct their resume before submission. Typos on a forum or on any casual internet medium seem to be a pretty bad way to judge a potential employee.
Bad Cover Letter:
Hai. I ams teh looking to joun ur companies. Plz 2b reding thru resume attachd. thx!