Using a generator to handle migrations


#1

James, on your presentation at railsconf (
http://rails-engines.org/news/2009/05/18/engines-at-railsconf/) you
suggest
(for now) making your own generator to handle the migrations issue. Can
you
elaborate on that method?


#2

Quoting Andrew R. removed_email_address@domain.invalid:

James, on your presentation at railsconf (
http://rails-engines.org/news/2009/05/18/engines-at-railsconf/) you suggest
(for now) making your own generator to handle the migrations issue. Can you
elaborate on that method?

I am not James - but I recently needed something like that. I used the
Clearance engine as a model for buillding the migrations I wanted.

http://github.com/thoughtbot/clearance/tree/master

James, is there video anywhere of your talk? I got a lot out of the
slides but there are a couple where I would like more detail as was
probably provided at the talk.

Cynthia K.


#3

Not sure if it’s useful information or not, but in the repository I
use for engines, I’ve made it simply use the current Rails migration
mechanism, ie, no generator is required, the migrations in plugins are
automatically ran.

My repository is way out of date though… I should really do a pull
to see if it works just fine with the recent changes.

Miles


#4

I’ve got a small plugin that might help you:
http://github.com/hpoydar/engines-helper


#5

2009/9/7 Cynthia K. removed_email_address@domain.invalid:

Quoting Andrew R. removed_email_address@domain.invalid:

James, on your presentation at railsconf (
http://rails-engines.org/news/2009/05/18/engines-at-railsconf/) you suggest
(for now) making your own generator to handle the migrations issue. Can you
elaborate on that method?

I am not James - but I recently needed something like that. I used the
Clearance engine as a model for buillding the migrations I wanted.

http://github.com/thoughtbot/clearance/tree/master

This is basically correct - you want to use the ‘migration_template’
method available in the generator mechanism to copy a migration file
into db/migrate, and Clearance is a reasonable example where this
happens.

The reason we do this is to place the migration in the appropriate
part of the application timeline; this is one of the issues I covered
in my presentation. You can see my blog for more discussion of this
(http://interblah.net/plugin-migrations), but the gist is that I
believe it is important to preserve the order migrations were applied.

The other part of the migration issue is tracking which migrations
have already run; there’s no reason why you couldn’t run the migration
generators from Clearance multiple times, for example. This isn’t a
big deal normally, but comes into play if you’re trying to ‘upgrade’
an engine in-place, and incorporate a new migration.

James, is there video anywhere of your talk? I got a lot out of the
slides but there are a couple where I would like more detail as was
probably provided at the talk.

There’s no video (probably for the best, to be honest), but I’m happy
to answer questions here, if you’ve got them.

  • James