Irrational Exuberance

You are writing a comment about How to Migrate Data Across Model Changes, here is a quick summary:

If you've built a large program in Django (or, ya know, anything that uses a database), you know about migrating data. Specifically, you know that you hate migrating data, and that you'd rather use a badly thought out model and waste hours with a bad design decision than simply fixing the tables and the existing data. Well, say goodbye to your data migration angst, 'cause baby, its going away.

You are responding to this comment written by Will Larson on January 31st 2008, 08:06.

Thanks for all the kind words Petr.

I think most people don't think about migrating this way because it can require a bit of wrangling by hand. Also, it requires a little foresight about how the different databases deal with data. Like how SQLite will willingly eat some data that PostgreSQL will reject. Really though, its how I migrate all my data changes.

My usual system is dumping it from the source (like the server running lethain.com), then reloading it and testing the model change on a development deployment and getting the data updated for it, then dumping that, and reloading the fixed set onto the production server. This means that I get to screw up my development server, which is okay, instead of my production server, which is... less good.

Anyway, take care, and let me know if you need any help with lifeflow.

Please be aware that comment forms go stale after one hour.

@@ ruby
def a (b, c):
  b * c
end
@@

 ### This is an h3 title
#### This is an h4 title
**this is bold**
*this is italics*

1. This is an
2. ordered list

* And an unordered
* list too

[this is a link](http://www.lethain.com/ "Lethain")