Webコピペ屋

「many-to-many（多対多）」をGAE上で表現してみる。
ネット上にこの手法の記事が少ないことからあまりメジャーなやり方でないかもしれないが、確実に言えることは接続用モデルを作ることで1kind増えるので関連データを引っ張ってくるのにデータストアの呼び出し回数が増える＝パフォーマンスに影響するということ。
それを踏まえた上で参考までに。

「one-to-many（1対多）」最後のパターンはエンティティグループを使った親子関係で表現するやり方。
many（多）である子が「parent」を使って親を指定します。モデル的には他の「one-to-many（1対多）」のように何らかのプロパティを用意する必要がありません。

「ListProperty()」を用いて1つのkindでone-to-many（1対多）のCRUDを作成してみる。

ケースは「Google App Engineでone-to-many（1対多）2kindとReferenceProperty()で」と同様、人物が複数のメールアドレスを持っている関係を表すこととする。
「ListProperty()」には特定の型のリストを格納することができます。
今回はメールアドレスですので、文字列「str」をしています。「item_type」は省略できるようなので、「db.ListProperty(str)」と「db.ListProperty(item_type=str)」とは同義です。

2つのkind（モデル）の連携を一般的な「ReferenceProperty()」を用いてone-to-many（1対多）のCRUDを作成してみる。
ケースは人物が複数のメールアドレスを持っている関係を表すこととする。

さらに今回は今後のためをふまえて機能にそってpyファイルを分けて構築してみました。

「Google App Engineでone-to-one（1対1）」で作成した複数モデル連携をDjangoフォームを導入したバージョンも作ってみる。
連携しているモデルを自動で引っ張ってきてくれてドロップダウンメニューを作ってくれるからこれまたかなり便利だが、フォームを生成している中身はまったくカスタマイズできない。
そういったかゆいところに手が届かない感じもあるが、例によって複数モデルでもバリデーションをしっかりやってくれるし、コードも短くなるので使ってもいいケースもあるかも。

いわゆる複数モデルの連携処理をCRUDで作ってみる。
one-to-one（1対1）といっても実はone-to-many（1対多）にもなる。正確にいうと1対1に抑えているだけの話。

一般的には「ReferencePropertyによるモデルの相互参照」という手法を使います。

「Google App Engineで「CRUD」1ファイル+テンプレート版」の記事でベタにCRUDを作成したが、フォームやバリデーション部分をDjangoのフォームにやってもらったものを作ってみました。
コード量は確かに減るし、バリデーションやエラー表示もやってくれるのでかなり便利。

確かに便利は便利なのだが…

Google App Engineでデータストアについて色々な記事を探していると、
「keyによるget()はとても早い」と書かれている記事をよく目にする。

以外に情報が少ないPythonでのCRUDのやり方。
処理ハンドラを1ファイルに全部詰め込み、出力はテンプレートを使用しています。

プレビューリリースから早2年。
開発環境も充実してきたようなのでGAE熱が再燃。

まずは「Hello world!」を数パターンで書いてみる。