返信する
fastapi response_modelでpydanticモデルの代わりにormarモデルを使用できます。
もちろん、必要に応じてormar. Modelsをpydanticと組み合わせて使用することもできます。
レスポンスで最も一般的なタスクの1つは、レスポンスデータに含めたくないフィールドを除外することです。
これはormarでさまざまな方法で行うことができるため、以下のオプションを確認して、状況に最適なものを選択できます。
応答からフィールドを除外します
オプションのフィールド
各オプションフィールドは必須ではないことに注意してください。つまり、応答とリクエストの両方でオプションフィールドをスキップできます。
(任意/多数/すべて)次の場合、フィールドは必要ありません。
- フィールドはnullable=Trueとしてマークされます
- フィールドにはデフォルト値または提供される機能があります。つまり、default="Test"です
- フィールドにはserver_default値が設定されています。
- Fieldはautoincrement=Trueprimary_keyフィールドです(ormarに注意してください。Integermain_keyはデフォルトでautoclimentです)
例:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 | |
上記の例では、フィールドid(自動増分整数)、first_name(nullable=Trueを使用)、およびカテゴリ(デフォルト値を使用)はオプションであり、応答でスキップでき、モデルは引き続き検証します。
フィールドを空にできる場合は、作成時やレスポンスのペイロードに含める必要がないため、上記の例に基づいて次のことができます。
1 2 3 4 | |
つまり、リクエストでie first_nameを渡さなかった場合、正しく検証され(フィールドはオプションであるため)、データベースに保存され、このフィールドなしで保存されたレコードが返されます(これも検証されます)。
!!!Noteフィールド値を渡していなくても、フィールド自体はresponse_modelに存在することに注意してください。
1 | |
FastApi応答_モデル_除外
Fastapiには、一連の(またはリストの)フィールド名を受け取るresponse_model_cludeがあります。
これには制限があります。ormarとpydanticは辞書も受け入れているため、除外/包含列をネストされたモデルに設定することもできます(詳細は以下を参照)
警告response_modelを使用する場合、必須フィールドは検証中に失敗するため、除外できないことに注意してください。
1 2 3 | |
上記のエンドポイントは次のように検索できます:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 | |
!!!(注)上の例のパスワードフィールドが応答データから完全に消える方法に注意してください。
1 | |
ネストされたモデルの除外
fastapiはフィールド名のセットのみを渡すことを許可しているため、単に除外しますが、response_model_排他を使用する場合は、ormarの方が賢明です。
ormarでは、2種類のシンボルを使用してネストされたモデルを除外できます。
1つ目は、モデルツリー構造を表すフィールドがネストされたディクショナリで、2つ目は、二重アンダースコアで区切られたフィールド名パスです。
ユーザーカテゴリが別のモデルであると仮定します。
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 | |
レスポンスのカテゴリから優先順位を除外する場合でも、fastapiパラメーターを使用できます。
1 2 3 | |
二重アンダースコアを使用してより深いモデルに入ることができ、ネストされたモデルから複数のフィールドを除外する場合は、それらの前にフルパスを追加する必要があることに注意してください。例では response_model_exclude={"category__priority", "category__other_field", category__nested_model__nested_model_field} ETC。
!!!注除外の可能性と、除外辞書または設定の構築方法の詳細については、ドキュメントのフィールドセクションを参照してください
注意fastapiはresponse_model_cludeパラメータの他にpydanticから継承した他のパラメータもサポートしていることに注意してください。これらはいずれもormarにも適用されますが、多少のニュアンスの違いがあるかもしれませんので、ドキュメントのdict部分を読んでおくとよいでしょう。
Model. model_dump()から除外する
または、ormar. Modelから辞書を返して使用することもできます。
このように、除外/インクルードを辞書として設定***ストされたモデル上のフィールドを除外することもできます。
!!!response_modelを使用しないことを警告すると、理論的には応答は任意の形式にすることができるため、APIドキュメントには応答の例とパターンがありません。
1 2 3 4 5 | |
!!!注上記の例では、リクエストでパスワードフィールドを渡してもパスワードフィールドは無効になりますが、応答スキーマの一部であり、値がNoneに設定されているため、このフィールドは存在します。
この方法でフィールドを完全に除外したい場合は、response_modelを使用せず、モデルのmodel_dump()で除外するだけです
または、ormarモデルからディクショナリを1つだけ返すこともできます。このように、除外/インクルードをディクショナリに設定して、ネストされたモデル上のフィールドを除外することもできます。
!!!注理論的には、ここでは応答の検証が失われますが、ormar. Modelsで操作しているため、データベースクエリの後に応答データが検証されます(ormarモデルはpydanticモデルであるため)。
そのため、response_modelを完全にスキップすると、次のようにできます。
1 2 3 4 | |
!!!注response_modelをスキップすると、返された後にレスポンスが検証されなくなるため、必須フィールドを除外できるようになりました。
1 | |
ormar. Modelからpydanticモデルを生成する
フィールドを除外するタスクは非常に一般的であるため、ormarには、すべてのフィールドを再入力することなく、既存のormar. Modelsからpydanticモデルを生成する特別な方法があります。
このメソッドは、すべてのモデルクラスで使用できるget_pydantic()メソッドです。
1 2 3 4 5 | |
!!!注さらに多くのサンプルを表示して詳細を読むには、ドキュメントのget_pydanticセクションにアクセスしてください。
警告get_pydanticメソッドは、モデル内のループを回避できるアルゴリズムに基づいて、ネストされたモデルツリー内のすべてのモデルを生成します(model_dump()、select_all()などで使用されるアルゴリズムと同じです)
1 2 3 | |
そうすれば、ツリーの異なる葉に異なるフィールドを除外/含めることができます。
独立したカンチレバーモデル
最終的な解決策は、個別のpydanticモデルを手動で作成することです。通常のfastapiアプリケーションとまったく同じように動作するため、異なるレスポンスとリクエストモデルなどを使用できます。
サンプル:
1 2 3 4 5 6 7 8 9 10 11 12 13 | |