djangoでカスタムモデルフィールドを定義するメソッドをオーバーライド

Question

私はPythonでカスタムdjangoモデルフィールドを定義しようとしています。私はdjangoドキュメントを以下の場所https://docs.djangoproject.com/en/1.10/howto/custom-model-fields/で参照しました。しかし、私は（私は私の理解あたりとしてグループに分かれています）、次の方法に比べて混乱しています： -

グループ1（このグループのメソッドは、ドキュメントごとに相互に関連している）

1. __init__（ ）
2. 解体（）

グループ2

1. DB_TYPE（）
2. rel_db_type（）
3. get_internal_type（）

グループ3

1. from_db_value（）
2. to_python（）
3. get_prep_value（）
4. get_db_prep_value（）
5. get_db_prep_save（）
6. value_from_object（）
7. は（）

グループは4

1. は

は、私は次の質問を持っていますFORMFIELD value_to_string： -

1. deconstruct()が使用されていますか？ Docsによると、移行中は便利だが、明確に説明されていない。さらに、それはいつ呼び出されますか？ value_from_object()とvalue_to_string()間get_prep_value()とget_db_prep_value()

2. 差とdb_type()とget_internal_type()

3. 差と

4. 違い。 value_from_object()はドキュメントに記載されていません。

5. from_db_value(),value_to_string()およびto_python()の両方は、stringからpythonオブジェクトを返します。そして、なぜこれらの異なる方法が存在するのですか？

私は少し長い質問をしました。しかし、この質問をよくするための他の方法を見つけることができませんでした。

ありがとうございます。

Answer 1

私はそれらに答えることをしようとするでしょう：

Q：deconstruct()が使用されていますか？

A：あなたは再作成、それはあなただけ__init__に渡される引数をもとにしてくださいFieldのインスタンスを持っている場合この方法が使用されています。 docsに記載されているように、max_length argを__init__メソッドの静的な値に設定すると、あなたのインスタンスのためにそれを必要としません。だからあなたのdeconstruct()メソッドで削除することができます。これにより、max_lengthはモデルで使用している間はインスタンスに表示されません。モデルでフィールドを使用する前に、最後の清掃と管理場所としてdeconstructを考えることができます。

---

Q：差A

db_type()間とget_internal_type()：それらは両方とも関連するが、異なるレベルに属します。

カスタムフィールドのデータ型が使用しているDBによって異なる場合、db_type()は、コントロールを実行できる場所です。ここでもdocsに記載されているように、フィールドが一種の日付/時刻値である場合、この方法で現在のデータベースがPostgreSQLまたはMySQLであるかどうかを確認する必要があります。 PostgreSQLにはtimestampという日付/時刻値がありますが、MySQLにはdatetimeと呼ばれています。

get_internal_typeは、db_type()の上位バージョンの一種です。日付/時刻の値の例を見てみましょう：各データ型が異なるデータベースに属しているかどうかをチェックして制御したくない場合は、built-in Djangoフィールドからカスタムフィールドのデータ型を継承できます。それがdatetimeかtimestampであるかどうかを調べる代わりに。 get_internal_typeメソッドでは単にDateFieldに戻ることができます。 docsに記載されているとおり、すでにdb_typeメソッドを作成している場合、ほとんどの場合、get_internal_typeメソッドは必要ありません。

---

Q：get_prep_value()とget_db_prep_value()

間差A：これらの人はまた、db_type()とget_internal_type()間almost同じロジックを共有します。まず第一に、これらの両方の方法は、db値をpython objectsに変換することを意味します。しかし、db_typeメソッドの場合と同様に、get_db_prep_value()はbackendの特定のフィールドタイプを表します。

---

Q：value_from_object()とvalue_to_string()間違い。ドキュメントから：value_from_object()がドキュメント

Aに与えられていない

値は、シリアライザによってシリアライズされる方法をカスタマイズするには、 value_to_string()を上書きすることができます。 value_from_object()を使用するのは、シリアル化の前にフィールドの値を取得する最も良い方法です（ ）。

実際には、value_from_objectは文書化されている必要はありません。このメソッドは、シリアル化の前にフィールドの生の値を取得するために使用されます。このメソッドで値を取得し、value_to_stringメソッドでシリアル化する方法をカスタマイズします。彼らはdocsでサンプルコードを入れ

---

Q：両方from_db_value()、value_to_string()とto_python()は、文字列からPythonオブジェクトを提供します。そして、なぜこれらの異なる方法が存在するのですか？

A：to_python()は有効なPythonオブジェクトにフィールド値を変換しながら、value_to_string()は、カスタムのシリアル化と文字列にフィールドの値を変換します。彼らはさまざまな仕事を表しています。

from_db_valueは、データベースによって返された値をpythonオブジェクトに変換します。実際にそれを聞いたことはありません。しかし、ドキュメントからthis partを確認してください。

データベース バックエンドはすでに正しいPythonのタイプ、または変換を行い バックエンド自体を返すように、この方法が最も組み込みの分野に使用されていません。