OpenAPITools / OpenAPITools/openapi-diff
Unify Handling of allOf/anyOf and oneOf in Diff logic
まだ誰も着手していません。
- 主要言語
- Java
- スター
- 1.1k
- フォーク
- 190
- PR マージ指標
- 30日以内にマージされた PR はありません
説明
Current Behavior:
The diffing mechanism currently handles allOf/anyOf and oneOf differently within composed schemas:
-
allOf/anyOf: These schemas are recursively resolved and their properties are merged into the parent schema before the main diffing occurs. This happens inSchemaDiff#resolveComposedSchema, where properties fromallOf/anyOfsubschemas are added to the parent usingSchemaDiff#addSchema. The originalallOf/anyOfstructure is effectively flattened. -
oneOf: These schemas are not merged beforehand. Instead, theComposedSchemaDiffResult#diffmethod performs a structural comparison of theoneOflists between the old and new schemas. It identifies added, removed, or changedoneOfoptions, storing the results in aChangedOneOfSchemaobject which is then attached to theChangedSchema.
Suggested Behavior:
This difference in processing leads to an inconsistency. While the merging for allOf/anyOf simplifies property comparison later, it loses the structural information about changes within the allOf/anyOf lists. Conversely, oneOf retains this structural information because it's crucial for understanding changes in available options.
Consider unifying the approach. Perhaps allOf/anyOf could also be compared structurally, similar to oneOf, to provide a more consistent and potentially more informative diff result regarding the composition itself, rather than just the flattened outcome. This would allow tracking additions, removals, or modifications within allOf/anyOf lists directly.
コントリビューションガイド
はじめの一歩
- issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
- 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
- リポジトリをフォークし、ブランチを切って変更します。
- issue 番号を参照したプルリクエストを送ります。
調査の方向性
まず SchemaDiff#resolveComposedSchema と SchemaDiff#addSchema を確認して allOf/anyOf がどのようにフラット化されるかを理解し、次に既存の oneOf 比較について ComposedSchemaDiffResult#diff と ChangedOneOfSchema を読みます。allOf/anyOf における構造の追加、削除、変更を、フラット化されたプロパティの変更と併せてどのように表現するかを定義します。diff が関連する詳細を失わずにコンポジションの変更を一貫して報告できれば完了です。
索引モデルが issue の本文から書いたものです。
評価
- 技術スタック
- java
- 領域
- api
- issue の種類
- 機能追加
- 難易度
- 5/5
- 見積もり時間
- 1週間以上
- 活発さ
- 停滞
- 明瞭さ
- おおむね明確
- 初心者へのやさしさ
- 35/100