Date Migrate

[Andrew Vargo]

Hey all,

I just released my first gem, Data Migrate.

The short:
Create migrations for data the same way you'd do it for your schema. Go forward, back, up, down, etc, just data, or smartly in conjunction with the schema.

For more explanation and usage:
http://ajvargo.com/2011/05/data_migrate/
https://github.com/ajvargo/data-migrate

Best,

Andrew

[Wyatt Greene]

Cool. I always love it when people experiment or add to existing Rails concepts.

Could you explain the benefit of having data migrations separate from schema migrations? Or perhaps explain a scenario that would be painful without data migrations but easy with them?

Thanks,
Wyatt

> --
> You received this message because you are subscribed to the Boston Ruby Group mailing list
> To post to this group, send email to boston-r...@googlegroups.com
> To unsubscribe from this group, send email to boston-rubygro...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/boston-rubygroup

[Chris Rhoden]

I can't tell for sure, but it looks like this might alleviate a specific painpoint I have run into when deploying a whole bunch of migrations at once when some of them adjust data.

Imagine that at some point you add a data migration which uses AR. In a future commit, you add a new column. In another commit, you add validations to this column, and a new data migration to bring your records into compliance.

Being able to run all of your schema migrations _and then_ all of your data migrations which use the model might be useful in this case.

I am probably not being clear, but I have occasionally reordered my data migrations to the end of a chain.

On May 2, 2011 8:45 PM, "Wyatt Greene" <techi...@gmail.com> wrote:

[Andrew Vargo]

Chris hit my painpoint dead on.

Its seems when a project hits a certain size, I get to manipulate data outside the application itself.  Changing defaults, new validations, one-to-one to one-to-many... I found it a pain and dodgy to have to step up migrations one by one, run a ruby script of some sort, then resume migrations.  It tanks a lot of the automation of deploy.  We update our seeding for development, and had some wacky stuff we tried that always bit.

The benefit of having them separate has to do with your data model.  For instance, lets take an absurd example, to illustrate: You have your infamous Rails blog that has posts with many comments.  After some use, you decide you are going to be a trend setter, and want only one comment per post, and just the text. "Frist!" rules the day. Given that you:

- write a migration to add a comment column to Post

- write a migration to move the contents of the first comments to the Post

- drop the column_id column from Post

- drop the Comment model.

- fix all your test/controller/view mojo.

You've just got bit.  When you rake setup:development, the mess gets mad at you after it creates your database, and starts cranking through migrations.  It gets to the part where you iterate over the comments and it blows up.  You don't have a comment model anymore for it to even try and get 'all' from.  You think you are smarter, and wrap the AR call in a conditional based on the environment. That's fine until you get that QA gal, and she wants her own thing. Then the UI people get tired of waiting for the full stack to load on page refreshes, so you have to edit past migrations...

With Data Migrate, you have the control.  You can generate your migrations as schema or data as you would as your work flow. For setting tasks that don't require any intermediate AR activity, like dev and test, you stick with db:migrate.  For your prod, and qa, you change their scripts to db:migrate:with_data.  Of course you want to test your migration, so you have the choice of db:migrate:with_data or data:migrate to just capture that data change.

-- Andrew.

[Wyatt Greene]

Thanks Andrew and Chris.  I've experienced similar problems with migrations.

I really like the separation of concerns.  Since schema migrations only change tables and columns, they are pretty much guaranteed to run successfully every time.

Migrations in Rails are sometimes used to recreate the database from scratch, so they get run from the beginning every so often.  Do the data migrations tend to be run only once?

--Wyatt