ちょっと検索すると本家MLの過去ログからビンゴなスレッドがありました。要はローカルからの接続時に認証を一旦外してパスワード変更後、元に戻すというものです。認証を設定しているのはpg_hba.confというファイルで僕の手元では下記の位置にありました。md5(パスワード認証)となっている認証形式をtrustに書き換えます。

$ sudo vim /Library/PostgreSQL/9.1/data/pg_hba.conf
- local   all             all                                     md5
+ local   all             all                                     trust

設定ファイルを修正後に再起動すると、postgresユーザでパスワードなしでログインできます。あとはALTER USERでパスワードを変更しましょう。

$ sudo -u postgres ./bin/pg_ctl restart -D/Library/PostgreSQL/9.1/data
$ psql -U postgres
postgres=# ALTER USER postgres WITH ENCRYPTED PASSWORD 'new password';
postgres=# \q

パスワードの変更が終わったら認証形式を元に戻しておきます。postgresユーザのパスワード忘れても何とか大丈夫なもんですね。

$ sudo vim /Library/PostgreSQL/9.1/data/pg_hba.conf
+ local   all             all                                     trust
- local   all             all                                     md5
$ sudo -u postgres ./bin/pg_ctl restart -D/Library/PostgreSQL/9.1/data
$ psql -U postgres
Password for user postgres:

一番最初に触ったデータベースがPostgreSQLだったので結構好きだったはずなんですけど、何年か使ってないくらいで綺麗サッパリ使い方を忘れていたので、ついでにちょっとだけリハビリです。

$ psql -U postgres
postgres=# \l      # データベース一覧
postgres=# \c db1  # データベース選択
db1=# \dt          # テーブル一覧
db1=# \d table1    # テーブルスキーマ
db1=# \d SELECT datname, pg_size_pretty(pg_database_size(datname)) FROM pg_database; # 各テーブルのサイズ
db1=# \q

herokuのShared Databaseもpsqlから接続できたら良いのになと思う今日この頃です。あとせめて50MBくらい容量欲しい。

mysql> status;
--------------
mysql  Ver 14.14 Distrib 5.1.51, for apple-darwin10.3.0 (i386) using readline 5.1
...
Server characterset:    latin1
Db     characterset:    latin1
Client characterset:    latin1
Conn.  characterset:    latin1
...
--------------

で、この設定のままutf8な文字列を突っ込んでて、でも別にmysqlコマンドやらpythonのMySQLdbやらから読み書きしても文字化けしないし、まぁ良いかと思ってほったらかしてた訳です。そしたらDjangoから読もうとしたら文字化けしたので、なんでやねんと思って調べたのでメモしておきます。

ちょっと調べたところDjangoはデータベースに対してutf8のデータを要求するようです。そうするとMySQLは自分の中にlatin1の文字列が入っていると思い込んでいるので、格納されている文字列をlatin1からutf8に変換しようとする訳ですね。結果utf8で格納されている文字列に対して、無理矢理latin1からutf8への変換をかけて化けるという事でした。

なぜDjango以外のケースで化けなかったかというと、クライアントがlatin1のデータを要求したせいで、データベースで変換処理が走らず、結果的には化けないと。まぁタマタマ動いていただけですね。ダメダメです。

さて化けてた理由はわかりましたが、すでにlatin1なテーブルにutf8で数十万件ほどデータを突っ込んでしまっています。my.cnfなんかで慌ててutf8な設定にしても当然解決されませんし、テーブルの文字コードを変更しても化けたままです。しょうがないから変換スクリプトでも書くかと思っていると、MySQLのリファレンスに解決方法が書かれていました。抜粋したものが以下になります。

ALTER TABLE t1 CHANGE c1 c1 BLOB;
ALTER TABLE t1 CHANGE c1 c1 TEXT CHARACTER SET utf8;

リファレンスによるとテキストなカラムとblobなカラム間では変換処理は走らないようです。なのでblobを経由させると変換処理を発生させずに、MySQLにデータに対する認識を変更できるという事ですね。この場合はlatin1だと思われているutf8な文字列を、utf8として認識させ直すことができました。ちなみに僕は一度blobを介さずにutf8にalter tableして、バックアップを取ってなくて終わったと冷や汗をかきましたが、すがる思いでlatin1に再度alter tableしたら、元通りになりました。運がよかったのか、そういうものなのかは未検証です。

という訳で、文字コードlatin1のまま使って、やっちまった!と思ったけど、ALTER TABLE使えば何とかなったという話でした。まぁ最初から文字コードくらいちゃんと設定しとけという事ですね。

[mysqld]
default-character-set=utf8

• SQLAlchemy
• SQLObject
• Elixir
• Storm

まず用途についてですが、僕はテーブルスキーマはSQLで直に書きますので、ORMでDDLを扱うつもりはありません。DMLを簡単に扱いたいというのが一番の目標です。そこで予め作成して置いたテーブルに対してCRUD操作のし易さを比べてみました。比較に使用したのは以下のテーブルです。

CREATE TABLE `books` (
  `id` INT(11) NOT NULL AUTO_INCREMENT,
  `title` VARCHAR(100) DEFAULT NULL,
  `price` INT(11) DEFAULT NULL,
  `isbn` INT(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `isbn` (`isbn`)
)

まず最初に試したのは、SQLAlchemyです。ちょっと検索した感じでは一番使われてそうな雰囲気です。早速使ってみたところ以下のようになりました。一連の初期化処理でセッションを作成し、セッションを通してオブジェクトの操作を行います。ソースを見ての通りCRUD操作自体は直感的に行えるのですが、マッピングを明示的に行う事や、セッションの管理やDBハンドルの管理などやや煩雑です。ただドキュメントを読む限りでは、非常に高機能で細やかな制御が行えるようです。感想としてはもう少しデータベースを隠蔽して欲しいと思いました。create_engineやget_session等は本来書きたい処理ではありません。

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import sys
from sqlalchemy import *
from sqlalchemy.orm import *
 
# booksテーブルとマッピングするクラス
class Book(object):
  def __init__(self, title, isbn=None, author=None, price=None):
    self.title  = title
    self.price  = price
    self.isbn   = isbn
 
# セッション(トランザクション)を取得する
def get_session(engine):
  Session = sessionmaker(bind=engine)
  return Session()
 
def main():
  engine = create_engine('mysql://root@localhost/sample', echo=True)   # echoでデバッグ出力
  meta   = MetaData(engine)
  books = Table('books', meta, autoload=True)  # autoloadでテーブル情報を自動ロードする
  mapper(Book, books)
 
  session = get_session(engine)
 
  # insert
  try:
    book1 = Book('1Q84', price=2000,  isbn=1234567)
    book2 = Book('リアル9', price=630, isbn=9876543)
    session.add(book1)
    session.add(book2)
    session.commit()
  except:
    print sys.exc_info() # duplicate error
 
  # select
  session = get_session(engine)
  for b in session.query(Book).all():
    print b
 
  # update
  for b in session.query(Book).all():
    b.price *= 1.05
  session.commit()   # just modify object's value and commit
 
  # delete
  session = get_session(engine)
  for b in session.query(Book).all():
    if b.price > 2000:
      session.delete(b)
  session.commit()
 
if __name__ == '__main__':
  main()

次に試してみたのがSQLObjectです。同じ処理を書いたコードが以下になります。SQLAlchemyと比べてとてもシンプルにまとまっています。セッション周りの煩雑なコードも不要ですし、またテーブル名を指定するだけで、自動的にカラムをロードしてくれるのも便利です。イメージしていたORMとかなり近く、もうこれで良いかなと思ったのですが、１つ気になる情報がありました。TurboGearsというWebフレームワークがバージョン1.xの際に採用していたSQLObjectを、2.xからSQLAlchemyに差し替えた事です。どうも複雑なデータベースを操作する際のパフォーマンスに問題があるというのが理由だそうです。

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import sys
from sqlobject import *
 
# 他の処理に先立ってconnectionを作っておく必要がある
sqlhub.processConnection = connectionForURI('mysql://root@localhost/sample?debug=1')
 
# booksテーブルにマッピングするオブジェクト
class Book(SQLObject):
  class sqlmeta:
    table        = "books"
    fromDatabase = True
 
def main():
  # insert
  try:
    book1 = Book(title='1Q84',   price=2000, isbn=1234567)
    book2 = Book(title='リアル9', price=630,  isbn=9876543)
  except:
    print sys.exc_info() # duplicate
 
  # select
  for b in Book.select():
    print b.title
 
  # update
  for b in Book.select():
    b.price = int(b.price * 1.05)
 
  # delete
  for b in Book.select():
    if b.price > 2000:
      Book.delete(b.id)
 
if __name__ == '__main__':
  main()

正直DBのパフォーマンスが問題になるようなアプリケーションは、まだ作れないのでSQLObjectでも良かったのですが、念のため他のORMを見ていると今度はElixirというモジュールが見つかりました。これはSQLAlchemyのラッパーで、乱暴な言い方をすればSQLAlchemyをSQLObjectの様に扱えるようになります。実際のコードは以下になります。マッピングが自動化されて、セッション管理なども簡潔に記述できるようになっています。

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import sys
from elixir import *
 
metadata.bind = 'mysql://root@localhost/sample'
metadata.bind.echo = True
 
# booksテーブルにマッピングするオブジェクト
class Book(Entity):
  using_options(tablename='books', autoload=True)
 
def main():
  setup_all()
 
  # insert 
  try:
    book1 = Book(title='1Q84',   price=2000, isbn=1234567)
    book2 = Book(title='リアル9', price=600,  isbn=9876543)
    session.commit()
  except:
    print sys.exc_info()
  session.close()
 
  # select
  for b in Book.query.all():
    print b
 
  # update
  for b in Book.query.all():
    b.price *= 1.05
  session.flush()
 
  # delete
  for b in Book.query.all():
    if b.price > 2000:
      b.delete()
  session.flush()
 
if __name__ == '__main__':
  main()

これはもうElixirで決まりと思ったのですが、ウノウラボのブログに「PythonのORMを研究してみる(1) 」という記事があり、そこでSQLAlchemyやSQLObjectが選択肢にある中でStormを紹介しますと言っているのが気になって、Stormでも書いてみました。以下がソースになります。オブジェクトのコンストラクタを自分で書かないと駄目なのが気になります。また僕の使い方が良くないのか、データベースに登録された日本語が化けてしまいました。

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import sys
from storm.locals import *
from storm.tracer import debug
 
class Book(object):
  __storm_table__ = 'books'
  id    = Int(primary=True)
  title = Unicode()
  price = Int()
  isbn  = Int()
 
  def __init__(self, title, price, isbn):
    self.title = title
    self.price = price
    self.isbn  = isbn
 
def main():
  debug(True, stream=sys.stdout)
  db = create_database('mysql://root@localhost/sample')
  store = Store(db)
 
  book1 = Book(u'1Q84', 2000, 123456)
  book2 = Book(u'リアル', 600, 987654)
 
  # insert 
  try:
    store.add(book1)
    store.add(book2)
    store.commit()
  except:
    print sys.exc_info()
    store.rollback()
 
  # select
  for b in store.find(Book):
    print b
 
  # update
  for b in store.find(Book):
    b.price *= 1.05
  store.flush()
 
  # delete
  for b in store.find(Book):
    if b.price >= 2000:
      store.remove(b)
  store.flush()
 
if __name__ == '__main__':
  main()

まとめ
というわけでまとめですが、上の４つでいうとElixirかSQLObjectが使い易いと思いました。オブジェクトとテーブルの自動マッピングが出来るのでコード量がかなり減ります。どちらを使うか迷うのですが、総合判断でElixirを使う事にしました。いざという時にSQLAlchemyの機能にアクセスできるのが、何となく安心だというのが理由です。

本来ならベンチマークを入れるべきところですが、それは又の機会という事で。

結論から言うとSQLiteで使えるCSVのインポート/エクスポートは制約が強くて使い辛いです。というのも、カラムの文字列内にセパレータ(標準ではカンマ)が含まれている場合は、クォートされていても、セパレータとして認識されてしまい、正常なcsvとして扱われないからです。(例えば”Hi, Nice to meet you.”は２カラムとして扱われます。)

ちなみにSQLite標準のインポート／エクスポートは以下のように行います。

# 標準で以下のようにインポート／エクスポートできるが、セパレータが上手くパースされない
.mode csv TABLE_NAME
# エクスポート
SELECT * FROM TABLE_NAME
# インポート
.import sample.csv TABLE_NAME

カラム内にセパレータが無ければ標準のままで行けますが、そんな事はイチイチ考えてられないので、pythonで簡単にインポート／エクスポートを実装してみました。

#!/usr/bin/python
# -*- coding: utf-8 -*-
 
import sqlite3
import csv
 
# SQLite内のデータはutf-8を想定
def sqlite2csv(db_name, table_name, out_filename):
  dbh = sqlite3.connect(db_name)
  writer = csv.writer(file(out_filename, 'w'))
  for row in dbh.execute('SELECT * FROM %(table_name)s' % locals()):
    writer.writerow([col.encode('utf-8') if isinstance(col, unicode) else col for col in row])
  dbh.close()
 
# csvのセパレータはカンマを想定
def csv2sqlite(db_name, table_name, in_filename):
  dbh = sqlite3.connect(db_name)
  reader = csv.reader(open("import.csv", "rb"))
  for row in reader:
    ph = "?," * (len(row) - 1) + "?"
    dbh.execute("INSERT INTO %(table_name)s VALUES(%(ph)s)" % locals(), tuple(row))
  dbh.commit()
  dbh.close()

これでSQLiteとCSVが相互に行き来できるようになりましたね。ま、最初からMySQL/PostgreSQLを使えよというのが最もかもですが。

最近頻繁にDBを弄っているのでイライラが募りまして、ALTER TABLEを覚えました。行の追加くらいしかした事が無かったのですが、結構色々できて便利です。

以下はMySQL限定です。他のDBは試していません。

1. SERIALの値をリセット
   基本的にテーブルにはauto incrementでidを作るのですが、
   このidに採番される値をリセットしたい事がよくあります。今までは一度テーブルを削除して作成し直していたのですが、ALTER TABLEで行えます。

   ALTER TABLE (テーブル名) AUTO_INCREMENT=1

2. 行の順番を変更
   ALTER TABLEで行を追加したは良いものの、列の順番が気持ち悪くて入れ替えたい事がよくあります。今まではレコードダンプを取ってテーブルに入れ直していましたが、これもALTER TABLEで行えます。

   ALTER TABLE (テーブル名) MODIFY COLUMN (カラム名) (カラム型) AFTER (移動先カラム名)

   また、そもそも行を追加するときに追加する位置を指定できます。

   ALTER TABLE (テーブル名) ADD COLUMN (カラム名) (カラム型) AFTER (追加先カラム名)

3. カラムの名前と型を変更
   僕はよくカラム名を変更したくなるのですが、これもALTER TABLEで行けます。

   ALTER TABLE (テーブル名) CHANGE (カラム名) (新しいカラム名) (新しいカラム型)

   ただし型を変えない時も、カラムの型を指定する必要があります。

4. データベースエンジンの変更
   WEBアプリとかをモックから徐々に作っていく過程でMyISAMからINNODBに変更したいシーンが時たまありますが、コレもALTER TABLEで行けます。逆も行けます。

   ATLER TABLE (テーブル名) ENGINE=INNODB

5. テーブル名の変更
   複数形のs付け忘れた時等に重宝します。

   ALTER TABLE (テーブル名) RENAME TO (新しいテーブル名)

6. 主キーの変更
   主キーの追加も可能

   ALTER TABLE (テーブル名) ADD PRIMARY KEY (カラム名);

   もちろん削除も可能

   ALTER TABLE (テーブル名) DROP PRIMARY KEY;

• 特定のテーブルのカラム定義を取得
  ALTER TABLE関係ないんですが、テーブルの定義を見るときに今まではshow column from (テーブル名) とかやってたんですが、desc (テーブル名)で同じ働きでした。タイプ数が結構減りましたね。

てかWP-SyntaxってSQLも対応してるんや。凄いな。

追記 2009.11.26
テーブル名の変更を加えました。

追記 2011.6.9
主キーの項目を追加しました