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)
@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?
@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.
On May 15, 9:31 pm, “Ryan B. (Radar)” [email protected]
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 
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:
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
On Sat, May 17, 2008 at 7:44 PM, Nathan E.
[email protected] wrote:
issues).
over
Automatically — err.the_blogPosted via http://www.ruby-forum.com/.
–
http://jeremymcanally.com/
http://entp.com
Read my books:
Ruby in Practice (Ruby in Practice)
My free Ruby e-book (http://humblelittlerubybook.com/)
Or, my blogs:
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.
And before you say it,
yes I could create a new migration and call drop_table in it, but then
that
defeats the purpose of only having one migration file.
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.
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.
–
Appreciated my help?
Recommend me on Working With Rails
http://workingwithrails.com/person/11030-ryan-bigg
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!
On Tue, May 20, 2008 at 1:46 PM, Nathan E. <
[email protected]> wrote:
–
Appreciated my help?
Recommend me on Working With Rails
http://workingwithrails.com/person/11030-ryan-bigg
On Sun, May 18, 2008 at 9:59 PM, Ryan B. (Radar)
[email protected] wrote:
And before you say it,
yes I could create a new migration and call drop_table in it, but then that
defeats the purpose of only having one migration file.
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.
–
Rick DeNatale
My blog on Ruby
http://talklikeaduck.denhaven2.com/