query-pipeline

クエリパイプライン

回帰テストの所有権

• クエリ仕様テストは、一貫性のあるクエリまたはモデルの特性ごとにグループ化してください。テストがカスタムモデルを使用するという理由だけで汎用の分類を作らず、所有エンティティクエリなど、既存の特性別階層を使用してください。
• 回帰テストの配置前に、仕様テストの基底クラスとプロバイダーによるオーバーライドを確認してください。LINQ クエリ、モデルのセットアップ、結果のアサーションは共有の仮想テストに記述し、プロバイダーのオーバーライドでは基底クラスを呼び出したうえで、プロバイダー固有のベースラインまたは既知の制限のみを追加してください。
• プロバイダー固有のテストでは、SQL のアサーションが正しくても、ほかのすべてのプロバイダーがテストされない場合があります。オーバーライドのガードは維持しつつ、無関係な冗長オーバーライドを強制するガードは追加しないでください。
• 最適化については、同期と非同期の両方で、最適化の対象となる形状と対象外となる形状を、結果の厳密なアサーションでカバーしてください。具体的なプロバイダーのオーバーライドと SQL ベースラインまたは既知の制限を用意してください。抽象テスト基底クラスや式の形状チェックだけでは、実行がカバーされていることを証明できません。

変換

• 変換のフォールバックでは、既知の未サポートな形状と予期しない不具合を区別する必要があります。任意の例外をフォールバックの成功として扱わないでください。
• 失敗した書き換えによって、フォールバックで再利用する状態が変更されていないか確認してください。テスト間の調整について、共有の静的状態が競合する可能性を主張する前に、実際のコレクション、アセンブリ、非同期フローの境界を確認してください。理論の行が本質的に並列実行されるわけではなく、finally でのリセットは相互排他ではありません。

最適化

• 式の等価性をそのまま適用するのではなく、書き換えに必要な等価性に合わせてください。
• コンテキストごとの NULL セマンティクスを維持してください。SQL の UNKNOWN は述語では false と同様にフィルターできますが、射影された値や否定の配下では同様に扱えません。UseRelationalNulls、NULL を含む IN／NOT IN、スカラーと複合の LINQ 結合キーでは、それぞれ異なる補正が必要です。
• 一致する行だけでなく、カーディナリティと演算子の順序も維持してください。外部結合をまたいで述語を移動すること、Distinct／GroupBy にキーを追加すること、相関のある APPLY を JOIN に変換することは、結果を変える可能性があります。親ごとのページネーションではパーティション分割と順序を維持し、残っている外部参照があれば非相関化を行わないでください。
• 評価と行の選択が等価な場合に限り、繰り返し使われるサブクエリを共有してください。揮発性の式、後続のナビゲーション展開時に導入されるクエリフィルター、必須ナビゲーションの結合は、評価回数や制限適用後に残る行を変える可能性があります。再利用の前に決定性と行の保持を確認し、候補はそれぞれのラムダスコープ内で収集してください。
• SQL の型付けと CLR の結果セマンティクスは、それぞれ個別に維持してください。ストア型への影響が冗長な場合に限りキャストを削除してください。定数へのキャストは、必要な SQL の型付けを確立する場合があります。SQL の NULL 許容列だけではシェーパーの NULL 許容性は決まりません。NULL 非許容スカラーに対する DefaultIfEmpty では、CLR の既定値を指定する COALESCE が必要になることがあります。
• クエリの形状を変更する場合は、依存する状態を再マッピングしてください。サブクエリのプッシュダウンや結合の置換では、スコープ付きの列参照、述語、順序付け、射影バインディング、シェーパーを更新する必要があります。多重度や NULL 拡張が変化する場合は、識別子とその比較子を保持するか再計算してください。
• 最終射影だけでなく、それ以上の範囲で枝刈りの安全性を証明してください。未使用の結合でも行のフィルターや増殖を引き起こす可能性があるため、明示的な枝刈り可能性とほかの句からの参照を考慮してください。参照されていない列でも、distinct／集合演算のメンバーシップやスカラーサブクエリの結果を定義することがあります。そうした契約と互換性のある集合演算の射影を維持してください。

分割クエリ

• SplitQueryResultCoordinator を変更する場合は、SplitQueryingEnumerable と GroupBySplitQueryingEnumerable の両方について、同期パスと非同期パスを確認してください。ストリーム終端の検証は、グループ境界や早期破棄時ではなく、外側のストリームが実際に終端に達したときに行います。
• グループ化されたリーダーは、最後のグループの組み立て中に物理的な EOF に達しても、そのグループはまだ返す必要がある場合があります。その正常な移動と、その後の終端への移動を分けてテストし、検証失敗と終端呼び出しの繰り返しも確認してください。クリーンアップでは、元の例外を保持する必要があります。
• メモリ使用量を評価する際は、呼び出し元によるマテリアライズだけでなく、内部バッファリングも考慮してください。プロバイダーが複数のリーダーを同時にアクティブにできない場合、先行する分割クエリの結果セットをバッファリングする必要があります。再試行を行う実行ストラテジーでも、バッファリングが必要になることがあります。
• バッファリングによって、別々のクエリコマンドが一貫性のあるデータベーススナップショットを取得できるわけではありません。コマンド間の同時書き込みにより、結果グラフに不整合が生じる可能性があります。一貫性が必要な場合は、プロバイダーのサポートとトランザクションのコストを考慮して、スナップショット分離またはシリアライズ可能トランザクションを検討してください。
• クロスコマンドの一貫性は、書き込みトランザクションと読み取り間に明示的なバリアを設けて検証してください。スリープや説明文だけのシナリオに頼らないでください。一致するキーだけでなく、ルートと子の値の組み合わせをアサートし、テストの分離レベルと再試行ストラテジーの適用範囲を明記してください。

検証

• ToQueryString() は、実行せずに生成された SQL を表示します。
• ExpressionPrinter は、パイプラインの任意の段階で式ツリーを出力します。
• SQL ベースラインはプロバイダーの機能テストで AssertSql() を使って検証され、生成された SQL が基底メソッドの LINQ クエリに対応していることを確認します。