0

基になるリポジトリが単なる配列であっても、IQueryableで動作するには、次のコードが必要です。これにより、メモリアレイバッキングストア内の偽物を使用した単体テスト中にNREがスローされます。明らかにy、特に左外部結合の後でnullになる可能性があるため、yそれ自体を助けることはできませんが、nullになります。

var x = from y in SomeIQueryable
        group y by y.someForeignKey
        into z
        select z;

以下に変更しました。

var x = from y in SomeIQueryable
        group y by y != null ? y.someForeignKey : null
        into z
        select z;

上記のようにグループを設定すると、実際のSQLバッキングストアに対して実行したときに問題が発生しますか？

4

2 に答える 2

0

一般に、このような変更によって問題が発生することはありません。その場合、基になるプロバイダーが何らかの理由でクエリを SQL に変換できないことを主張する例外を生成します。はい、問題はプロバイダー固有のものであり、一般的に誰も答えることができません.

より新しい T-SQL (SqlServer) の場合、(IIRC) group-by で計算された列を使用できるので問題なく動作するはずです。SQL の場合、提供する式はまさにこれです: 計算された列です。

ただし、他のトラップには細心の注意を払う必要があります。たとえば、値渡しと変数渡しの場合、null チェックの動作が異なります。

クエリに正確に含まれる場合、SQL バックエンドx != nullで変換されます。x NOT NULLただし、値を名前でキャプチャすると、ローカルであっても、つまり. int? blah = null; .... from ... x != blahその後、EFはそれを「誤って」変換します.コードは意図x <> @paramし@param = NULLたとおりに機能しません..

C#<->SQL 変換には、このようなわずかなニュアンスがもっとあります。ただし、提供された正確なコードには危険なものは見当たりません。見た目は問題ありません。一度試してみて、 のようなものがスローされない場合はNotSupportedException、適切に動作すると想定できます。linq プロバイダーは通常、一部の式を適切に変換できない場合、そのクラスの例外をスローします。

于 2012-08-22T07:39:11.097 に答える
0

このようなチェックに関する私の経験では、EF はそれらをサポートしており、それらを正しい SQL に変換します。ただし、生成された SQL には null チェックが含まれ、少なくとも SQL Server ではクエリのパフォーマンスが多少低下します。複雑なクエリの場合、それが顕著になります。

しかし、2 番目の形式がクエリで十分に機能する限り、おそらく十分です。

于 2012-08-22T07:29:17.377 に答える