このブログでも数回紹介していたとおり、今メジャーな Python の MySQL ドライバ3つのうち2つ (MySQL-python の fork の mysqlclient と PyMySQL) を僕がほぼ単独でメンテナンスしている状況でした。 メンテナンスしているといっても、両方とも MySQL-python との互換性を第一に掲げているので、 Python 3 対応が終わった後はほとんど進化は無くて、淡々とバグの修正を積み重ねては1年に1度以上リリースするという程度です。 実際には Python では PostgreSQL 周りに比べて MySQL 周りは遅れていて幾つか改善案はあったのですが、子育てや他にも Python でやりたい事があったり仕事でも Go で楽しんでたりして手を付けられていませんでした。 そんな状況の中、 Mike さんが PyMySQL-Users ML に突
libmysqlclient を利用した Python の MySQL ドライバである libmysqlclient-python を、 gevent, meinheld など非同期I/O + 軽量スレッド環境で使いやすいようにしました。 libmysqlclient の API について libmysqlclient は基本的に同期IOのことしか考えられていません。 ですが、クエリを投げてそのステータスを返す mysql_real_query() に限り、代替手段として mysql_send_query() でクエリを送信してから、ステータスを待つ mysql_read_query_result() を呼ぶという事ができます。 また、 MYSQL 型の net.fd というメンバから fd を取得することができます。 これらを組み合わせて、 mysql_send_query() でクエリ
前回の記事で しかし、長年の実績がある本家といえども、個人プロジェクトで、１年に数回しかコミットされてない現状です。 一応、「いま転職直後で時間ないんだけど、できれば週末に見ておくよ」という感じのレスを貰ったのでしばらく待ってみますが、進展がなければ別名で PyPI に登録してしまうつもりです。 と書いたのですが、まだ本家にマージされていないので、娘が家に来てあまり活動ができなくなる前にリリースしてしまいました。 mysqlclient Windows 用には、今風のバイナリパッケージである wheel をビルドしてあります。 ビルドに必要だった MySQL Connector/C が、インストーラを使うと、 x86 と x64 が排他になる（片方をインストールするともう片方が自動的にアンインストールされる）ので地味にハマりました。 Windows 版の wheel の準備は、 Windo
去年10月に Python 3 の MySQL ドライバ事情 という記事で次のように書いていました。 多分デファクトスタンダードな MySQLドライバなのですが、現状リリースされている 1.2.4 では Python 3 対応ができていません。 Fork の MySQL-for-Python3 が推奨されます。 最近 MySQL-python の方に Python 3 対応の準備的な Pull Request (古い構文を Python 2/3 両対応の構文に置き換える) がちらほらあり、やっぱり中途半端にメンテされてない Fork より本家に対応してもらわないとなぁということで、エイヤで Python 3 対応してしまって 少し大きめの Pull Request を投げました。 しかし、長年の実績がある本家といえども、個人プロジェクトで、１年に数回しかコミットされてない現状です。 一応、
このblogは、著者である「sakito」が技術的に生存している事を報告するために存在します タイトルを「紹介マニアどらふと版」から変更しました 概要 Python から MySQL に接続するためのドライバは複数存在している。どれを使うのが一番良いのか確認してみる。 Python の MySQLドライバ Python の MySQLドライバの主な物は「MySQL - PythonInfo Wiki」に記載されている。 以下のような物がある。記事を書いた時点でのpypiでの最終リリース日の新しい順。 リンク Python3対応 DB API v2.0対応 ライセンス メンテナー 最終リリース日 概要
はじめに Djangoを使ったアプリケーションで、2つのバッチ処理用プロセスA、Bを同時に立ち上げたときに、Aのトランザクションでsave & commitした値をBでは読み取れないという問題に直面しました。 問題の箇所のソースコードはこのような感じです。 実行順 プロセスA プロセスB 1 with commit_on_success(): p = Post(id=1) p.save() 2 # saveしたデータが見える Post.objects.get(id=1) 3 with commit_on_success(): p = Post(id=2) p.save() 4 # saveしたデータが見えず例外発生 Post.objects.get(id=2) Djangoではデフォルトで自動コミットが有効なので、Aでコミットした値をBで読み取れるはずと思っていたのですが、これは間違いでし
Django 1.2 はマルチDB対応ができまして、master/slave レプリにも対応しているのですが、詳しく見るといろな問題が出てきます。 Django 1.2 のマルチDB対応は どのDBから、読み込むか、どのDBに書き込むかがDBルータで決める。しかし、そのルータで決める時点でリクエストオブジェクトにアクセスできないので、レプリラグのどを自動的に対応するのが難しい。 レプリケーションを使っている場合、マスターDB に書き込んだ時に、データがスレーブDBまで流れるラグがあるので、DBに書き込んだデータがすぐDBから取れない場合がある (eventual consistency)。 obj = MyModel.objects.create(content="Hello World") obj.content = "Hello World!" obj.update() # 失敗する可
HowFriendFeedUsesMySqlToStoreSchemaLessData - FriendFeed では MySQL を使いどのようにスキーマレスのデータを保存しているのか 目次 この記事について FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか 背景 概観 詳細 一貫性と原子性 性能 FriendFeed? では MySQL を使いどのようにスキーマレスのデータを保存しているのか この記事について "How FriendFeed? uses MySQL to store schema-less data" の日本語訳です http://bret.appspot.com/entry/how-friendfeed-uses-mysql CC 2.5 でライセンスされています: http://creativecommons.org/
1
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
