alembicをrailsと比較しながら使ってみた
はじめに
LangChainとDBの連携のサンプルコードを書いてる中で、唐突に出てくるテーブルの構造も一緒に置いておかないと、後で見たときにわからなくなるなと思い、alembicを触ってみることに
環境の分け方が色々ある
ここで言う環境というのは、developmentとかproductionのことになりますが、
venvなどを実行した後、alembic init
を実行すると↓のようなiniファイルができます。
iniファイルか、、、と思ったんですが、変数は埋め込めるようです。
また、AWS Secrets Manager
などに保管すると思うので、環境変数を埋め込みたいです。
そういえば、FastAPIってどうしているのかと、思って調べるとこんなファイルを見つけました。
alembic.iniのsqlalchemy.url
の部分がないですね。代わりにenv.pyで設定しています。潔い感じがします。とりあえず、これを採用することに。
create databaseはやってくれないらしい
alembic revision -m "create products table"
のような感じで、
rails g migration
的なことを行いproductsテーブルの定義を追加してみました↓
railsと違って、rollback(alembicだとdowngrade)する場合のdrop_tableは書かないといけないみたいです。
その後、alembic upgrade head
を実行すると
sqlalchemy.exc.OperationalError: (MySQLdb.OperationalError) (1049, "Unknown database 'alembic_practice'")
(Background on this error at: https://sqlalche.me/e/20/e3q8)
となります。
下記を見るとやっぱりcreate databaseやってくれないみたいです。
mysqlだとcollationとかcharsetとか気になるので、どこかにcreate文を置いておきたいですが、ちょっといい方法が見当たらなかったです。
docker環境なら、docker-compose.ymlに
のような感じで設定しておくので、予想がつきそうではありますが。気を取り直して手動でDBを作成して、
alembic upgrade head
を実行します。
そうすると、
CREATE TABLE `products` (
`id` int NOT NULL AUTO_INCREMENT,
`name` varchar(50) COLLATE utf8mb4_bin NOT NULL,
`description` varchar(200) COLLATE utf8mb4_bin DEFAULT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_bin
こんな感じで出来上がりました。
同時に、alembic_versionテーブルも下記のように作られます。
ただ、railsのschema.rbのようなものはデフォルトでは出力されないので、
alembic upgrade head --sql > migration.sql
を実行するか、下記を参考にしてカスタマイズしていくようです。
終わりに
内容的には大したことがなかったですが、新しいライブラリを使うときには、最初は苦労が多いなと改めて思いました。
Discussion