Squash migrations. #304

merged 1 commit into from Nov 28, 2012

3 participants

Refinery member

This also makes sure tags and taggings tables doesn't exist before
trying to create them - #294.

@ugisozols ugisozols Squash migrations.
This also makes sure tags and taggings tables doesn't exist before
trying to create them.
@parndt parndt merged commit f906ef0 into master Nov 28, 2012

1 check passed

Details default The Travis build passed
Refinery member

What did this fix, exactly? Was it fixed by squashing the migrations or by removing all the calls to .table_name thus avoiding loading the models?

Refinery member

1) squashed everything (except taggings) into one file
2) removed table_name calls
3) made sure taggings table doesn't exist before trying to create it

That's about it.

Refinery member
Refinery member

Are you upgrading from latest 2.0.x? In theory every migration should have been run so it shouldn't be a problem to upgrade since this only squashes migrations into one.

Refinery member

In theory, but in practice this is not the case sometimes..for example @chrisftw has been having problems with this.

Refinery member

I'm guessing he's missing some of the migrations. Either way I'm fine with revert.

Yeah I was missing a migration, It was not too hard to go back and find the one I was missing and pull it forward, (which I did). Just seemed to be extra work that some people might get stuck on, and was not the "rails way". (I secretly Squash migrations in my own private projects all the time, but if two or more developers are using it there is always a chance to cause problems.)

Refinery member

Ugh this just caused me issues

Refinery member

If merged, fixed by #339

Please check that the migrations all look correct.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment