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).
I 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.
[+] [-] moe|15 years ago|reply
[+] [-] jarin|15 years ago|reply
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).
[+] [-] kinofcain|15 years ago|reply
http://datamapper.org/ https://github.com/datamapper/dm-rails
Datamapper was one of the great parts of the Merb framework, and with rails 3 you can use it in place of Activerecord.
[+] [-] nwjsmith|15 years ago|reply
[+] [-] jackseviltwin|15 years ago|reply
[+] [-] epochwolf|15 years ago|reply