Selective migrations possible?

Rails
1

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

2

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.

3

OK.

Also, I was just thinking: if I create models and then, without a
migration, create corresponding tables, I have sidestepped the
problem, such as it is.

Anyway, I’ve registered your skepticism.

Thanks,

Grar

4

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

5

On 19 March 2010 16:07, Grary [email protected] 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.

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

6

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

7

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

8

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

9

Thanks Jeff. That’s a lot to digest, but I will and likely try it,
too.

Grar

10

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

11

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