月: 2021年1月

[Django]複合主キー

０．Djangoは複合主キーをサポートしている？

https://docs.djangoproject.com/ja/3.1/faq/models/#do-django-models-support-multiple-column-primary-keys

https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys

Djangoでは複合主キーのサポートは公式にはされていない。※対応するパッケージとして以下を提供済み

[Django]django-compositepk-model

「primary_key=True」が指定されているフィールドが無い場合は、自動で「id」が主キーとして追加されて動作するようなので、従来システムのDBを使っている場合、モデルを使った更新、削除が、このままでは動作しない。テーブルにidフィールドを追加するか、独自のクエリで処理する必要がある。

１．解決方法

案１：サロゲートキーを追加する

サロゲートキー(“id”)をDBに追加して、複合キーには一意制約（unique_together）を設定すれば、Djangoのモデルがそのまま使える。

（問題）DBの再構築に時間がかかり、計画停止が必要。

案２：独自クエリ―にて実装する

ORMに頼らずに、自分でクエリ―を書く実装にする。クエリの性能面等を自分でコントロールできる。

（問題）コードとテストが増える。

案３：Modelを拡張する

Djangoプロジェクトでも以前に検討されたようだが、最近はどうなっているかは、よく分からない。

https://code.djangoproject.com/ticket/373

https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys#CurrentStatus

色々、挑戦した人もいるみたいだが、結局、どれも未完か？

とりあえず、自分でモデルを拡張することで、自分の仕事で使えるように、Modelのサブクラスを作成する。とりあえずは、Djangoのすべての機能をカバーする必要はないので、あくまでも自分が必要とする単体モデルのINSERT,UPDATE,DELETEがカバーできるものならできそう。

（問題）現状のModelのコードを理解する必要がある。

案４：別のORMを作る

モデルまわりのコードを見たが、少しスパゲッティな感じもした。ざっと実装を調べていて感じたのは、Model、Manager、QuerySetでの役割がきれいに分かれてないように見受けられた。複合キー対応も含めて、簡素な自分のORM作るほうがいいような気もする。

（問題）そんな時間は無い！

案５：既にある別のORMを使う

以下は、主キーではなくて、あくまで複合外部キーのためか？

https://github.com/Arisophy/django-composite-foreignkey

（問題）適切なものが見つからない

２．結論

今のプロジェクトは、Ruby On Railsで作られたレガシーなシステムを、徐々にDjangoに移行しているところで、DBに手を加えたくない。

結論として、案２と案３で進めることにした。

INSERT,UPDATE,DELETEについては、案３でModelの拡張クラスで対応する。実際に作ってみたら、少ないコードで、いい感じで動いている。このままその拡張モデルを使いながら、プロジェクトを進めていく。

SELECTについては、そもそも、すべてORMに頼るわけにはいかないので、独自クエリ―も利用する。

拡張クラスをどう作ったかは、後日、公開します。

(2021/01/29)

以下で、パッケージを公開しました。

https://github.com/Arisophy/django-compositepk-model

(2021/06/06)

パッケージの日本語説明

[Django]django-compositepk-model

(2021/03/16)

Djangoのticket373についての自分の見解は以下。

[Django]ticket#373

[Django]DB操作

１．モデル

https://docs.djangoproject.com/ja/3.2/topics/db/models/

１．１　オブジェクトの取得

オブジェクトを取得する

１）全件取得

MyModel.objects.all()

２）１件の取得

get() を用いて1つのオブジェクトを取得する

３）複雑な条件

以下で様々な条件が作れる。

Q オブジェクトを用いた複雑な検索

Field lookups

集計して、さらにその条件で検索するような場合は、以下を参考。

アグリゲーション

Filtering on annotations

１．２　リレーション

リレーション

関係により、以下クラスでFieldを定義する。リレーションを定義された側のモデルでは、自動で小文字のモデル名でフィールドが作成されて利用できるようになる。

反対向きのリレーション

１）多対一 (many-to-one) 関係

class ForeignKey(to, on_delete, **options)

必須ではありませんが、ForeignKey フィールド名 (上記の例では manufacturer はモデル名を小文字にしたものをおすすめします。

Djangoドキュメント：モデル-リレーション

２）多対多 (many-to-many) 関係

class ManyToManyField(to, **options)

３）一対一 (one-to-one) 関係

class OneToOneField(to, on_delete, parent_link=False, **options)

オブジェクトのhasattrは、以下でやる。

hasattr(object, 'field_name')

https://docs.djangoproject.com/ja/3.1/topics/db/examples/one_to_one/#one-to-one-relationships

４）実装例

Examples of model relationship API

５）その他

・キーは、無指定の場合、モデル名＋’_id’となる。違う定義の場合は、db_columnで指定する。

Database Representation

・逆側のリレーションを作りたくない場合は、「related_name=’+’」

https://docs.djangoproject.com/ja/3.1/ref/models/fields/#django.db.models.ForeignKey.related_name

２．独自のクエリ

１）カスタムSQLの操作

https://docs.djangoproject.com/en/3.1/topics/db/sql/#executing-custom-sql-directly

２）トランザクション制御

https://docs.djangoproject.com/ja/3.1/topics/db/transactions/

明示的にトランザクションをコントロールする

３）素の SQL 文の実行

https://docs.djangoproject.com/ja/3.1/topics/db/sql/#performing-raw-sql-queries

３．複合主キーの扱い

https://docs.djangoproject.com/ja/3.1/faq/models/#do-django-models-support-multiple-column-primary-keys

https://code.djangoproject.com/wiki/MultipleColumnPrimaryKeys

複合主キーはサポートされていなくて、「primary_key=True」指定されているフィールドが無い場合は、「id」が主キーとして動作するので、従来システムのDBを使っている場合、モデルを使った更新、削除が、このままでは動作しない。テーブルにidフィールドを追加するか、独自のクエリで処理する必要がある。

３．Manager

３．１　カスタムマネージャーの作成

DB取得等のロジックをViewの中に色々書くのもいまいちなので、カスタムマネージャーを作成する。

(Django公式)マネージャーのカスタマイズ

上記の日本語版は、翻訳が微妙で間違った解釈になるところがあるので、英語版を読んだ方が良さそう。

(Django公式)Custom managers

拡張クラスにメソッドを定義、あるいはget_querysetを書き換える等をコーディングするなり、QuerySetを定義するなりする。以下に４パターンの方法が記載されている。

（Django公式ドキュメント）

①カスタムMangerにメソッド追加する方法

Adding extra manager methods

②カスタムMangerの初期クエリセットを変更する方法

Modifying a manager’s initial QuerySet

③QuerySetを拡張してメソッド追加する方法

Calling custom QuerySet methods from the manager

④QuerySetを複数拡張する場合に、Managerをクエリセットから定義できる方法

Creating a manager with QuerySet methods

上記から適切な方法で実装していく。

４．QuerySet

https://docs.djangoproject.com/ja/3.1/ref/models/querysets/

WordPressのXserverへの移行

お名前.comのレンタルサーバーから、Xserverのレンタルサーバーへ移行した。WordPressの移行については、「WordPress簡単移行」で移行した。

https://www.xserver.ne.jp/manual/man_install_transfer_wp.php

便利で楽にできていいのだが、ただ、一つのサイトだけデータ移行のところで失敗して移行できなかった。

【原因】

プラグインの「Google Map WP」がDBでバイナリデータを使っていて、それが通常方法でdumpした場合には復元できないためエラーとなるよう。

【対応方法】

「WordPress簡単移行」を使いたい場合は、一旦、「Google Map WP」プラグインを削除してから移行して、その後、Xser ver側で再度、プラグインを入れるしかないか。

そうじゃなければ、自分で移行する。

https://www.xserver.ne.jp/manual/man_install_transfer_wordpress.php

その場合、DBバックアップ時には「–hex-blob」オプションを指定すること。

https://dev.mysql.com/doc/refman/5.6/ja/mysqldump.html#option_mysqldump_hex-blob

OSSへの参加

Djangoで開発している中で、汎用的なクラスを公開したほうがいいのかなと思い、今までは躊躇していたが、OSSに参加することにした。利用させてもらうだけというのも、確かに申し訳ないし。

まずは、GitHubで業務に関係のない共通的なクラスで、他の人にも役立ちそうなものを登録して、Djangoコミュニティーにも参加していこうかと思う。

１．GitHub

仕事関係は、自分でGitサーバーを立てて管理していたが、共通ライブラリーはGitHubに入れるようにする。

１．１　オープンソースについて

まずは、オープンソースについて知識を入れる。

オープンソースガイドライン

１．２　マークダウン言語

https://guides.github.com/features/mastering-markdown/

https://gist.github.com/mignonstyle/083c9e1651d7734f84c99b8cf49d57fa

１．３　レポジトリーを公開

最初の公開レポジトリーを作成した。

https://github.com/Arisophy/django-searchview

２．Django

（オープンソースとしてのDjango)

https://docs.djangoproject.com/ja/3.1/#the-django-open-source-project

(DjangoのGitHub）

https://github.com/django/django

２．１　Djangoメーリングリストへの参加

まずは、開発者メーリングリストに登録した。

https://docs.djangoproject.com/ja/3.1/internals/mailing-lists/#django-developers

３．パッケージを作る

パッケージを作って、以下に登録した。

https://pypi.org/

最初のパッケージは、以下を作った。

https://pypi.org/project/django-searchview-lib/

３．１　パッケージ作成手順

https://packaging.python.org/tutorials/packaging-projects/

１）以下コマンドでパッケージ作る

python setup.py sdist bdist_wheel

２）パッケージをアップロード

（テスト環境）
python -m twine upload --repository testpypi dist/*

（リリース）
python -m twine upload dist/*