[ANN] Branchable migrations -- A plugin to let you organize your migrations

Rails
1

I just put a new plugin named branchable_migrations on Github.
Branchable migrations lets you separate your migrations into
“branches” (i.e., a director under db/migrate) that each have their
own version. Using the forthcoming UTC timestamped migrations and
this plugin, you can separate migrations by table or feature. Doing
so should alleviate many of the problems that seem to pike up when
working on teams and using migrations for everything.

For example, if your db directory looked this:

db/
migrate/
001_create_things.rb
002_create_pandas.rb
branch1/
001_create_comments.rb
002_create_replies.rb
branch2/
001_create_posts.rb

Then running rake db:migrate would look like this:

– Executing migrations in root…

== 1 CreateThings: migrating

– create_table(:things)
→ 0.0195s
== 1 CreateThings: migrated (0.0199s)

== 2 CreatePandas: migrating

– create_table(:pandas)
→ 0.0195s
== 2 CreatePandas: migrated (0.0199s)

– Executing migrations in branch1…

== 3 CreateComments: migrating

– create_table(:comments)
→ 0.0032s
== 3 CreateComments: migrated (0.0035s)

== 4 CreateReplies: migrating

– create_table(:replies)
→ 0.0032s
== 4 CreateReplies: migrated (0.0035s)

– Executing migrations in branch2…

== 5 CreatePosts: migrating

– create_table(:posts)
→ 0.0032s
== 5 CreatePosts: migrated (0.0035s)

And your schema_info…

version branch
1 branch2
2 branch1
2 root

There are still a few bugs in the code to work out and a number of
ugly spots, but it works. Suggestions, pull requests, patches,
bugfixes, and complaints welcome. :slight_smile:

–Jeremy

–
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:

http://rubyinpractice.com

2

Jeremy -

On 3-Apr-08, at 12:06 AM, Jeremy McAnally wrote:

Then running rake db:migrate would look like this:
nice thinking Jeremy.

I wonder if this could be used to more easily coordinate developers
(rather than IMing “I’m creating a migration #202!”).

But I think for this use-case we’d want to run all 001’s, then all
002’s, etc.

Or do you think your system could apply?

Jodi

3

That wouldn’t be hard to hack in. Possibly like a “rake db:migrate
SYNC=true” would run the same versions across all branches. What do
you think?

–Jeremy

On Thu, Apr 3, 2008 at 11:13 AM, Jodi S. [email protected] wrote:

own version. Using the forthcoming UTC timestamped migrations and
branch1/
(rather than IMing “I’m creating a migration #202!”).

But I think for this use-case we’d want to run all 001’s, then all
002’s, etc.

Or do you think your system could apply?

Jodi

–
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:

http://rubyinpractice.com

4

Jeremy -

On 3-Apr-08, at 3:27 PM, Jeremy McAnally wrote:

Jeremy -

so should alleviate many of the problems that seem to pike up when
002_create_replies.rb
But I think for this use-case we’d want to run all 001’s, then all
002’s, etc.

Or do you think your system could apply?

Jodi

Yes - that might work.

(thinking out loud)I think it’s great as it makes migration collisions
less likely - and team members we’d just then have to manage dependent
migrations (ie. john’s migration 002, depends on bill’s migration 002)

I like. And would use.

Jodi