メンションすみません 🙇 @tarepan @sabonerune

どういう時にSkipJsonSchemaを付けるんでしたっけ。。。。。。
あとseparate_input_output_schemasオプションに関しても議論していた記憶があるんですが、どういう方針なんでしたっけ。。。

とりあえず課題感メモまで。

• 多分今の API は Noneを受け付けられるのに受け付けられないようなモデル構造になってる
  • Noteのkeyとか
  • この辺別に破壊的変更にならないのでちゃっちゃと変えて良さそうな気がする
• 多分Noneを受け付けられるものはSkipJsonSchemaをつけなくて良い
  • 既存のモデルは互換性というか、openapiが変わらないようにするためにSkipJsonSchemaがついてる？
  • 新しく作られるモデルはSkipJsonSchemaをつけなくても良さそう
• 「キーが必須ではない」というものと、「キーが必須だけどNoneが受付可能」なのがあった気がする
  • 前者はどう定義するのが良いんでしたっけ。。。。。。。。デフォルト値を設定する････？
• あとseparate_input_output_schemasって結局どうすれば良いんでしたっけ。。。

どういう時にSkipJsonSchemaを付けるんでしたっけ。。。。。。

キーが必須ではないがOpenAPIスキーマー上でnullを許容しないと表現するときに使用します。(変わるのはスキーマだけなのでnullを与えてもエラーになりません)

これが重要になるのがFasrAPIのQuery()、Body()、Form()です。
この部分のNoneにSkipJsonSchemaをつけないとSwagger UIの表示が壊れます。
(恐らく規格上nullと要素が存在しないを区別して送る方法が定義されていないことが原因だと思います。)

• 多分今の API は Noneを受け付けられるのに受け付けられないようなモデル構造になってる
• 多分Noneを受け付けられるものはSkipJsonSchemaをつけなくて良い

Modelの方はSkipJsonSchemaを付けなくても問題はないと思います。(最初にPR出した時点ではつけていませんでした。)

• 「キーが必須ではない」というものと、「キーが必須だけどNoneが受付可能」なのがあった気がする

「キーが必須ではない」はデフォルト値を設定すればいいです。
「キーが必須だけどNoneが受付可能」はNone許容型にしてデフォルト値を省けばそのようになるはずです。

あとseparate_input_output_schemasって結局どうすれば良いんでしたっけ。。。

入力のモデルと出力のモデルが異なるとき(キーが必須ではない等)OpenAPIに記述されるされるスキーマが*-Inputと*-Outputに分けられて記述されるようになります。
これの挙動がFastAPIのドキュメントと微妙に違ったりどうやっても破壊的変更になってしまうのではと考えてたので無効化しました。

正直よく分かっていないのですがこれを有効化するとスキーマーを作った時点で分割されているスキーマーは一つにならないように、最初は一つだったものは分割されないように機能追加する必要がでてくるので有効化するのは無理な気が…

うおーーーーありがとうございます！！！　非常に助かります！！！

そうか、APIの引数だと話が別なんでした！！
UIが変になるからという文脈も思い出しました！！

Modelの方はあるべき姿にしていっちゃいたいですね！
覚えてるうちにやっちゃおうかな。

separate_input_output_schemas

正直よく分かっていないのですがこれを有効化するとスキーマーを作った時点で分割されているスキーマーは一つにならないように、最初は一つだったものは分割されないように機能追加する必要がでてくるので有効化するのは無理な気が…

なんとなくオンにできない可能性がありそう、というのは同感です。

分割周りの話はちょっとよくわかんなかったです！（少なくともAが互いに疎なBとCに分かれるという分割は起こらない認識。）
実際にどういう処理になるのか把握していませんが、想像するに、返り値がNoneにならないこともある| Noneな型とか、返り値もキーが必須でない値とかあったときに変なことになりそうな直感。

とりあえず、よくわからないし＆わかろうとすると大変そうだからそのままオフにしとく･･･的な考えに至りました 😇
ありです！！