Hi,
I prefer to keep one migration per model, but lately I'm adding data that's expensive to drop every time I change my models.
How do I db:drop and db:migrate only selected tables/files? Basically, I want to ignore certain tables and migrations altogether during certain development phases.
Thanks,
Grar
Grary wrote:
Hi,
I prefer to keep one migration per model, but lately I'm adding data that's expensive to drop every time I change my models.
So don't do that. You've chosen to fight a (very) hard battle if that's the manner in which you are trying to use migrations.
Down the road, when you want to add a column to a table that has 100,000 rows of data, you're going through a backup and restore for that table just so you can have a single migration file per table???
If it really is just a preference, as opposed to a hard-driven requirement, then embrace the multiple migrations convention.
How do I db:drop and db:migrate only selected tables/files? Basically, I want to ignore certain tables and migrations altogether during certain development phases.
The weasely approach would be to leave all the migration files in place, and edit the contents of the migration files before you do any migrations, up or down. If you don't want to perform a step, comment out all the business logic inside that migration file, leaving just a self.up (or self.down) that does nothing. Sounds like a royal PITA to me.
I've registered your skepticism.
Yes, I can't see that the benefit of satisfying my preference here outweighs the burden.
That said, I still think it's a drag to sift through multiple migration files.
Thanks,
Grar
Hi,
I prefer to keep one migration per model, but lately I'm adding data that's expensive to drop every time I change my models.
It is considered a bad idea to seed data using migrations, if that is what you are doing. Google for rails migration seed for many discussions on this issue, including on this list. Perhaps this is your fundamental problem.
Colin
Yes, I've certainly given the role of seed data due consideration in another context, but it's not relevant in the case at hand, I don't think. In that case at hand, the large data set I seek to include in my development is used for autocompletion and by business logic on the model side.
Thanks,
Grar
Hi Grar,
If you really want to call a single migration, you could do something like:
$ ./script/console ...
require "#{RAILS_ROOT}/db/migrate/100_create_foos.rb"
=> ["CreateFoos"]
CreateFoos.down
== CreateFoos: reverting ============================= -- drop_table(:foos) ...
ActiveRecord::Base.connection.tables.include?('foos')
=> false
CreateFoos.up
== CreateFoos: migrating ============================= -- create_table(:foos) ...
ActiveRecord::Base.connection.tables.include?('foos')
=> true
And/or roll such calls into a runnable script and run it via runner:
$ cat ./script/migrate_foo.runnable require "#{RAILS_ROOT}/db/migrate/100_create_foos.rb" CreateFoos.down CreateFoos.up
$ ./script/runner ./script/migrate_foo.runnable ...
Personally, I like to keep my migrations intact as well, one per persistable model ob, unless I'm working on a project with a team that doesn't. This way it's easy for devs to see exactly what's defined at that time in the db for a given model ob, without having to weed through all the various modifying migrations related to some model ob, or looking for such info in the development_structure.sql if available, or having to fire up the console or an underlying db qry tool to see that model ob's current db schema.
For all my projects, I usually dev a runnable re-init script that contains all of the work (that I would typically call by hand) required to put the env in the current valid working state: run migrations, load any init data as required for the env, perform any post-init processing of data, run tests, etc.
Whenever a new migration is added or an existing one is modified or init data is added/modified, I just make one call to re-init the dev env. Note that the same holds true for pulling and re-init'ing some version from svn/git/....
When it comes to upgrading the production env for a new release that requires db-related changes, I dev a runnable script per prod env upgrade that performs the necessary work to upgrade the prod env to be in line with that particular release: run pre-upgrade tests to see if upgrade can/should be performed, run specific migrations and/or db schema mods as applicable, load any data and/or perform any data updates, run post-upgrade tests, etc.
Whenever a prod env upgrade needs to be performed, I dump the prod env db as a pre-upgrade backup, run the upgrade script to pre-test the prod env, upgrade the prod env, and post-test the prod env, and when all is good, dump the db again as a post-upgrade backup. (I usually test each upgrade scripts against a similar version/state of the dev env prior to performing the upgrade on the prod env, and once the script's working as intended, then I just re-init the current dev env.) Having such prod env upgrade scripts (and related db dumps) makes it equally easy to revert back to a specific state of the prod env as well.
Jeff
Thanks Jeff. That's a lot to digest, but I will and likely try it, too.
Grar
I prefer to keep one migration per model
It's a bad an unmaintainable idea. I did that when I was a beginner in RoR.
Simply create migrations to add/remove columns to existing tables. When you have too many migration files, simply remove them. The whole schema is saved in schema.rb
It's the same basic strategy I've been using successfully for the past 15+yrs dev'ing and maintaining web apps, using various mvc frameworks, langs, etc. Don't follow it if you don't want, but it's one that's worked well for me, based on real-world experience, and saved me a lot of time/headaches.
Jeff
Fernando,
When you say...
"When you have too many migration files, simply remove them."
...I think this means that you refer to the schema as the one source of summary information and that migration files are not informative except when a developer wants to revert to an earlier stage via 'redo' or 'version'.
Grar