November 15, 2012 Database Migrations with Alembic, SQLAlchemy and Flask Recently I started using Alembic for managing database migrations for a Flask application at work. Alembic is developed and maintained by the maker of SQLAlchemy, thus it was immediately an attractive tool. I've been using it the last month or so and without a doubt I've had a pleasant experience using it so far. In this post
セッションを使う¶ SQLAlchemy でオブジェクト・リレーショナルマッパを設定するときには、 Mapper を API のエントリポイントに使います。しかし、 ORM を使うときにもっ ともよく扱うのは、セッション (Session) で す。 セッションの役割¶ 大雑把に言えば、 Session は、データベース との対話を全て担当し、データベースから読み出したり生成したマッピングインス タンスを「保存しておく場所」です。セッションは Unit of Work パターンを実装しているので、オブジェクトに加えられた全ての変更を追跡して、 適時変更部分をデータベースに flush します。セッションのもう一つ重要なポ イントは、セッションがインスタンスの 一意な コピー、すなわち「あるプラ イマリキーに対応するただ一つのオブジェクト」を保持しているということです。 これは、いわゆる I
今まではwaitress上でWebアプリケーションを動かしていました。 コマンドひとつですぐに利用出来るので開発時には便利ですが、本番環境ではnginxとuwsgiを連携して動かしてみたいと思います。 前回までのエントリー Pyramidのインストールまで サーバーの起動まで MySQLの設定 waitressで動かしていた時はすべてのリクエストをuwsgiで処理していました。 そのためプログラムを必要としないリソースファイル(画像ファイル、スタイルシートなど)も処理対象となります。 特に処理が必要ないのであればnginxがそのままレスポンスを返して、処理が必要な場合だけuwsgiに流します。 イメージ nginx(80port) -> uwsgi(unix socket) 前回のmysqlと同様にuwsgiをsetup.pyに追記します。 requires = [ 'pyramid',
SQLAlchemyで1つのテーブルに複数種のリレーションを貼る ある1つのテーブルに複数種のリレーションを貼りたい。 前提 「映画」と「言語」を対象に考えてみると、ある映画と言語には2つの関係が持たせられる: その映画がどの言語を対象にしたものか その映画は元々どの言語のものなのか 例えば日本語吹き替え版「バックトゥザフューチャー」は、対象言語が日本語で、 元言語が英語ということになる。 これについてのテーブルを考えて、FilmとLanguageという2つを用意する。 Filmには対象言語へのFKであるlanguage_idと、元言語へのFKであるoriginal_language_id の2つを持たせてやる。もちろんFKの対象はLanguageテーブルである。 こういったテーブルがある場合に SQLAlchemy でどうやって対応するのかという話。 ちなみに議題にあげたテーブルはMyS
alembic使ってみた。sqlite以外のDBで使っていない。内容はまとまっていない。 alembic sqlalchemyのmigrationツール。sqlalchemy-migrateの代替として利用可能。 doc: http://readthedocs.org/docs/alembic/en/latest/index.html install $ pip install alembic 使い方 初期化 インストールするとalembicコマンドが使えるようになる。これを使って初期化を行う。 $ alembic init <dir> init実行後のディレクトリは以下のよう。( =alembic) . ├── alembic │ ├── README │ ├── env.py │ ├── env.pyc │ ├── script.py.mako │ └── versions └── a
僕はOracleでRDBMSとかSQLを勉強した人間なので、絶対に外部キーを張り、可能であればチェック制約もかけて、絶対に不正なデータは入れさせたくないと思う人間なのだが、LAMPサーバーを並べてスケールさせるっていう今時のサイトでは、外部キーを張らない設計の方が主流らしい。・・・本当！？確かに、アプリケーションやORMで頑張れば、外部キーを張るメリットが消え、外部キーを張るデメリットだけが残り、そしてMySQLはRDBMSではなく、SQLをサポートする単なるストレージになるだろうが・・・ちなみにSQLAlchemyならばテーブル定義から外部キーを消しても、mapperの定義で明示的に示してやれば、いままで通りのコードが動くはず。以下は「飼い主(Owner)と犬(Dog)の間に一対多の関係がある」という場合の例。 # -*- coding: utf-8 -*- from sqlalchem
前回は sqlalchemy-migrate を使ってみたから、今回は同様に Python のマイグレーションツールの Alembic を使ってみる。 Alembic もバックエンドに SQLAlchemy を使っているらしい。 Alembic を pip (PyPI) からインストールする。 インストールすると "alembic" コマンドが使えるようになる。 # pip install alembic $ pip freeze Mako==0.7.3 MarkupSafe==0.15 SQLAlchemy==0.8.0 alembic==0.4.2 wsgiref==0.1.2 $ alembic --help usage: alembic [-h] [-c CONFIG] [-n NAME] …(snip)…
Python の sqlalchemy-migrate は Ruby on Rails の ActiveRecord::Migration を、バックエンドに SQLAlchemy を使って再実装したもの。 ちなみに Python のマイグレーションツールには他に Alembic ってのもあるらしい。 マイグレーションツールを使うと RDB のスキーマ管理で楽ができる。 まず sqlalchemy-migrate を pip からインストールする。 現在最新の sqlalchemy-migrate (0.7.2) では SQLAlchemy 0.8.X がサポートされていないため、あえて 0.7.X がインストールされるようにバージョンを指定する。
written on July 19, 2011 Without doubt are most new Python web programmers these days chosing the Django framework as their gateway drug to Python web development. As such many people’s first experience with a Python ORM (or maybe an ORM altogether) is the Django one. When they are later switching to something else they often find SQLAlchemy unnecessarily complex and hard to use. Why is that the c
とりあえず導入部分だけざっくりと。 データベースへの接続 SQLAlchemy from sqlalchemy import create_engine engine = create_engine('sqlite:///:memory:', echo=True) peewee from peewee import SqliteDatabase engine = SqliteDatabase('db.sqlite') engine.connect() peeweeでsqlite:///:memory:する方法はめんどくさくて調べてません... ※2012.1.15 追記 peewee.SqliteDatabase(":memory:")でいけた モデルの定義 SQLAlchemy from sqlalchemy import Column, Integer, String, BOOLEAN
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
