def invalidate(self, obj=None):

Set an object or all objects to be invalidated.

This prevents Storm from returning the cached object without first verifying that the object is still available in the database.

This should almost never be called by application code; it is only necessary if it is possible that an object has disappeared through some mechanism that Storm was unable to detect, like direct SQL statements within the current transaction that bypassed the ORM layer. The Store automatically invalidates all cached objects on transaction boundaries.

http://twistedmatrix.com/users/radix/storm-api/storm.store.Store.html#invalidate

これだけじゃ、ダメで、

    store.flush()
    store.invalidate()

とした後で使わないと、データベースとstorm.storeの同期が取れていない状況になる。

トリガーでバリバリとStormの知らないところでデータを変更していると、わかりにくいエラーになってしまう。

ちなみに、更新後にstore.commit()を発行していればこういう問題は起きない。

ユニットテストでロールバックしながら繰り返しテストしていてはまった。

SQLAlchemyでも同じだよなあ。後で調べる。

SQLAlchemy http://www.sqlalchemy.org/

新しいプロジェクトのモデルをSQLAlchemyで書いてみようかとやってみたけれど、難しくて、なかなか理解が進まない。

ドキュメントは豊富だし、きっちり感があるし、ちゃんと理解できればいいんだけれど。

いろいろ調べてみたけれど、PostgreSQLのスキーマの取り扱いがどうもちょっと変な気がする。使い方が悪いのか、調べ方が悪いのか目先の問題を解くためには、もっと多くの知識が必要な感じ。

で、

Storm https://storm.canonical.com/

Stormでやってみたら、ほぼ同様のことがあっさりできた。

Clean and lightweight API offers a short learning curve and long-term maintainability.

こっちにするかあ。ドキュメントは事実上チュートリアルだけ。でもまあなんとかなる。

SQLAlchemyのMetaData.reflect()相当をどうしようかと探したら、こんなのが見つかった。

https://lists.ubuntu.com/archives/storm/2008-March/000521.html

これは助かる。Viewをテーブル同様に扱うので、少し困ったけれど何でもないね。

ドキュメントが少ないのが気になるけれど、このぐらいのサイズのライブラリならなんとか読めそうな気もする。

排他的でもないから、SQLAlchemyの学習もしながら、基本的にはStormを使うという感じで行ってみようか。