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

[Jeremy McAnally]

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. :)

--Jeremy

--
http://jeremymcanally.com/
http://entp.com

Read my books:
Ruby in Practice (http://manning.com/mcanally/)
My free Ruby e-book (http://humblelittlerubybook.com/)

Or, my blogs:
http://mrneighborly.com
http://rubyinpractice.com

[Jodi Showers]

Jeremy -

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

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

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

[Jeremy McAnally]

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

--

[Jodi Showers]

Jeremy -

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