http://nakagami.blog.so-net.ne.jp/2010-04-27-1
Django は使っていても、south は使ってない状態が半年くらい続いていたのだが、最近また使うようになった。慣れが必要で良くわからないまま使うとハマることもあるので、不馴れな開発メンバーがいる場合には使わない選択もありだとは思うのだが、久々に使い始めたらやっぱ便利だ。
スキーマーが激しく変わる開発段階では特にありがたい。
スキーマの変更（フィールドの追加とか、インデックス張るとか）は、 schemamigration に --auto オプションを付けると、モデルを見てうまいことやってくれるのだが既存データの変換を migrate で一緒にやりたい場合には、datamigration を使うらしい。
今回、 datamigration を使う機会があったのでメモ。
（お題）
「アプリケーション foo のモデル Foo の description フィールドに None(NULL)が入っていたらブランク('') に変更したい」
【1. datamigration で空のmigration script を作る】
datamigration <アプリケーション名> <スクリプト名>で、<スクリプト名> に数字の prefix のついた空のスクリプトができる。
下の例では 0003_setblank.py というスクリプトができる
$ python manage.py datamigration foo set_blank
Created 0003_set_blank.py.
【2.その中の forwards() というメソッドの中を書き換えてデータ変換する処理を書く】
（変更前）
class Migration(DataMigration):
def forwards(self, orm):
"Write your forwards methods here."
...
（変更後）
class Migration(DataMigration):
def forwards(self, orm):
for foo in orm.Foo.objects.all():
if foo.description is None:
foo.description = ''
foo.save()
ちなみに、
backwards(self, orm) に処理を記述すると１つ前の状態に戻すこともできたりするらしいが、今回は戻しようもないし（元々ブランクだったものと区別つかないので NULL に戻せない）省略した。
今までは、schemamigration だけ使っていたのだがそれでも特に困ってなかった。多分、データのマイグレーションをしたい場合は、スキーマを変更したあとで、手入力で SQL 文を実行していたのだと思う。今回も、datamigration 使わなくても、 SQL 文でできたわけだし。
でもまぁ、時間的余裕があれば、migration script 作ったほうが自動化できていいよなぁ。
datamigration については、 「Python プログラミング（BP Book）」から、south のチュートリアルを読むと良いと教えてもらった。
http://ae35.bitbucket.org/south-doc-ja/tutorial/part3.html
]]>
]]>
今度はすずめのひなが拾われて持ち込まれた
運動会に来るたびに、「いろんな家庭があるなー」と思う。
