Reversible Migrations in Rails 3.1
edgerails.info
Reversible Migrations in Rails 3.1
1–10 of 35 posts
Re: Reversible Migrations in Rails 3.1
#2About time. This has bugged me for years.
Re: Reversible Migrations in Rails 3.1
#3Wake me up when they finally generate those stupid migrations automatically (see http://south.aeracode.org/docs/tutorial/part1.html#changing-...).
Re: Reversible Migrations in Rails 3.1
#4Wake me up when they finally generate those stupid migrations automatically (see http://south.aeracode.org/docs/tutorial/part1.html#changing-... ).
That probably won't happen (anytime soon at least), because Rails takes the approach of generating your model attributes based on the table fields, not Django's (equally valid) approach of declaring the model attributes on the model and then generating the migrations based on that.
Personally, I prefer the Rails way of doing it, since it keeps my model files cleaner and avoids ambiguity (to me) when adding/removing/changing attributes. Of course, there is a tradeoff in increased startup time because Rails has to analyze your tables, but PassengerPreStart pretty much takes care of that annoyance for me (and I use background processing that doesn't require the Rails environment be instantiated for every job).
Re: Reversible Migrations in Rails 3.1
#5Wake me up when they finally generate those stupid migrations automatically (see http://south.aeracode.org/docs/tutorial/part1.html#changing-... ).
That probably won't happen (anytime soon at least), because Rails takes the approach of generating your model attributes based on the table fields, not Django's (equally valid) approach of declaring the model attributes on the model and then generating the migrations based on that. Personally, I prefer the Rails way of doing it, since it keeps my model files cleaner and avoids ambiguity (to me) when adding/removing/c…
I too prefer Rail's approach. However, I disagree that Django's approach is equally valid :-)
I've written about this before, but here's the short version:
1) The database holds the authoritative schema. You shouldn't duplicate it in your code.
2) What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway.
3) Including column declarations in your model forces the database's strong typing system onto what should be plain old Ruby/Python objects. The result is ineffective domain objects.
Re: Reversible Migrations in Rails 3.1
#6Earlier quoted context omitted.
That probably won't happen (anytime soon at least), because Rails takes the approach of generating your model attributes based on the table fields, not Django's (equally valid) approach of declaring the model attributes on the model and then generating the migrations based on that. Personally, I prefer the Rails way of doing it, since it keeps my model files cleaner and avoids ambiguity (to me) when adding/removing/c…
I too prefer Rail's approach. However, I disagree that Django's approach is equally valid :-) I've written about this before, but here's the short version: 1) The database holds the authoritative schema. You shouldn't duplicate it in your code. 2) What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway. 3) Inclu…
Well, yeah I totally agree. I didn't want to start a flame war :)
Re: Reversible Migrations in Rails 3.1
#7I like that the author added a section on demystifying the magic involved in how reversible migrations actually work. I like knowing how things actually work behind the scenes. I'd like to see the Rails community put less emphasis on the magic and more on how things work.
Re: Reversible Migrations in Rails 3.1
#8Earlier quoted context omitted.
That probably won't happen (anytime soon at least), because Rails takes the approach of generating your model attributes based on the table fields, not Django's (equally valid) approach of declaring the model attributes on the model and then generating the migrations based on that. Personally, I prefer the Rails way of doing it, since it keeps my model files cleaner and avoids ambiguity (to me) when adding/removing/c…
I too prefer Rail's approach. However, I disagree that Django's approach is equally valid :-) I've written about this before, but here's the short version: 1) The database holds the authoritative schema. You shouldn't duplicate it in your code. 2) What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway. 3) Inclu…
I have to say that i prefer the Django/sqlalchemy way.
I know that i'm probably duplicating code, but with this way, i don't have to look at the database to know which properties a model has, i just have to go to the .py file.
Also, i can use migrations as well to make sure the database is with the right version.
Re: Reversible Migrations in Rails 3.1
#9I've been using `:Rinvert` in rails.vim to accomplish the same thing for the last couple of months. Extremely useful.
Re: Reversible Migrations in Rails 3.1
#10Earlier quoted context omitted.
That probably won't happen (anytime soon at least), because Rails takes the approach of generating your model attributes based on the table fields, not Django's (equally valid) approach of declaring the model attributes on the model and then generating the migrations based on that. Personally, I prefer the Rails way of doing it, since it keeps my model files cleaner and avoids ambiguity (to me) when adding/removing/c…
I too prefer Rail's approach. However, I disagree that Django's approach is equally valid :-) I've written about this before, but here's the short version: 1) The database holds the authoritative schema. You shouldn't duplicate it in your code. 2) What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway. 3) Inclu…
> The database holds the authoritative schema.
Why?
> You shouldn't duplicate it in your code.
If the database does not hold the authoritative schema, you're not duplicating anything.
> What if you want to do something more complicated, like split the values in one column into two columns? You're going to need support for manual migrations anyway.
Of course, but it's not like the generated migrations are special. They're just written for you by the migration tool. One thing I'm sure you'll agree with is that computers are good at grunt, non-creative work. If the computer can write a migration, why not let it do so?
> Including column declarations in your model forces the database's strong typing system onto what should be plain old Ruby/Python objects. The result is ineffective domain objects.
Hogwash.