Topic: redesign instead of refactoring

Hi folks!

I have a general question for the re-design of a running application.
I think you all know the situation, when refactoring would be much more complicated than an elegant redesign. I my situation, I need an improvement of my very first rails-app.

How do you do this with data-models and their migrations? I have a bunch of migrations in the old app, to create the models. In the new one, I'll make some improvements to the data-models (e.g. split one table into two tables, when seperating a model). But I have to use the old production-data and therefore I have to modify them.

Should I write a rake-task, to perform this action *once*, or take the old schema.rb as the origin of my new app and write the migrations based on the old schema?
If anyone of you has some experience on this topic, please let me know, how you did it. Any other suggestions are welcome.

Kind regards,
Florian

Re: redesign instead of refactoring

FloWi wrote:

Hi folks!

I have a general question for the re-design of a running application.
I think you all know the situation, when refactoring would be much more complicated than an elegant redesign. I my situation, I need an improvement of my very first rails-app.

How do you do this with data-models and their migrations? I have a bunch of migrations in the old app, to create the models. In the new one, I'll make some improvements to the data-models (e.g. split one table into two tables, when seperating a model). But I have to use the old production-data and therefore I have to modify them.

Should I write a rake-task, to perform this action *once*, or take the old schema.rb as the origin of my new app and write the migrations based on the old schema?
If anyone of you has some experience on this topic, please let me know, how you did it. Any other suggestions are welcome.

Kind regards,
Florian

I would build it from the ground up with all new data (obviously when you run tests they use an empty db + fixtures anyway so the emptiness shouldn't be a problem).  Once you're happy with it then write some migrations to pull data from the other database and populate your new models tables with that data.  Trying to rebuild it around an existing schema will mess your head up - better to make a shiny new schema and then pour the data into it at the end.

###########################################
#If i've helped you then please recommend me at Working With Rails:
#http://www.workingwithrails.com/person/ … i-williams

Re: redesign instead of refactoring

I've done both. Rewrite and refactor. Often times, refactoring turns out to be a huge pain because you forgot some nuances in the code. I've cleared out migrations before and just threw it into my first rewrite, which seems to have worked well. Simply copying the schema.rb won't matter, because that is automatically generated. The migration history is kept in the schema_migrations table in your DB.

Re: redesign instead of refactoring

I'm glad quigebo pulled this up again because I now have basically the same question as FloWi did. Max or anyone else can you give a bit more detail on how you might take existing data from a database and migrate it to a whole new schema. For example one thing I know I will have to do is Take one model (A) and break it into two models (A & B), but for some of the old As I'll need a new A and TWO Bs. (e.g., A.x => A.x, A.y => B.x, A.z => B.x)

I hope that makes sense.

Re: redesign instead of refactoring

I did this about a year ago, migrating an old PHP app to Rails.  The approach I used was pretty much like the one laid out in this presentation, but this is a little cleaner.  Check it out: http://www.slideshare.net/mokolabs/migr … egacy-data

Re: redesign instead of refactoring

Thanks for the start elliot. It sure would be nice if I could get the actually presentation to watch the demo as well. I'll have to look at the code on github too.