問題タブ [deferred-execution]

どうしてこれなの？コードを調べてメッセージ/Tracをコミットしましたが、これが当てはまる理由はわかりません。これを回避する最も明白な方法はDeferred、をタプルに入れることですが、そもそもなぜこの制限があるのでしょうか。

注意：これは何よりも好奇心の質問です。

各ウィンドウList<Window>に、コレクションからウィンドウを削除するCloseイベントに関連付けられたイベントがある場合、コレクションが繰り返されるまで、デリゲート/イベントを使用してCloseイベントの実行を延期するにはどうすればよいでしょうか。

例えば：

具体的には、CloseAllWindows()メソッド内で、コレクションを反復してcloseイベントを呼び出すことができますが、コレクションが完全に反復されるまで、発生するイベントを延期できますか？

私はVS2010でデバッグしていて、文字列値を検査したいのですが、デバッガーに表示させることができるのは（ウォッチ、ホバリング、ローカルなどを介して）次のとおりです。

時期尚早の評価などによる副作用があるかどうかは気にしません。現在のブレークポイントで今すぐ評価すると、式がどのように評価されるかを確認したいだけです。

これはどのように行われますか？また、以前に評価されるようにコードを変更できますか? デバッグしていないときは気にしませんが、ただ疑問に思っています。

関連する場合に備えて...（私はそれを疑っています。）データベースに保存する前に新しいエンティティオブジェクトを詰め込んでいます...一部のフィールドにはLINQステートメントが割り当てられていますが、それらがいつ評価されるかわかりませんEFのカバー。DB の更新が「string or binary data would be truncated...」で失敗するので、長すぎるフィールドを見つけようとしています。

ロックステートメントにyieldreturnがある場合、各yieldでロックが解除されますか（以下の例では5回）、またはリスト内のすべてのアイテムに対して1回だけロックが解除されますか？

ありがとう

私のアプリケーションスタックに渡されたドメインオブジェクトの奇妙なハイブリッドIQueryable<T>とコレクションとして見ることができるものがあります。IList<T>「遅延クエリ」または「遅延読み込み」をできるだけ多く維持しようとしています。私はこれを2つの方法で行います。

1. LinqToSqlデータレイヤーを使用し、IQueryable<T>リポジトリを介してアプリレイヤーにsを渡す。
2. 次に、アプリ層がIList<T>sを通過した後、オブジェクト/集計グラフの特定の要素がデリゲートと「チェーン」され、読み込みが延期されます。IQueryable<T>デリゲートのコンテンツでさえソースに依存し、DataContext注入される場合があります。

これは今のところ私にとってはうまくいきます。

やみくもに難しいのは、この設計が実際に機能することを証明することです。つまり。どこかで「怠惰な」部分を打ち負かし、評価/実行が早く行われた場合、すべてが時間の無駄になります。どういうわけかこれをTDDできるようにしたいと思います。

同じソースで動作するデリゲートに適用されるため、デリゲートやスレッドセーフについてはよくわかりません。両方の関数がアプリ/スタックの異なるレベル/レイヤーで動作していることを証明するテストを行えるように、読み込みDataContextを延期する両方の方法（のSQLとデリゲート）をモックしてトレースできるようにしたいと思いますIQueryable<T>。

設計が任意の値になるように延期が機能することが重要であるため、（実際の実装とは別に）特定のレベルで設計を壊したときにテストが失敗することを確認したいと思います。これは可能ですか？

実稼働 SQL2000 インスタンスには、数百のストアド プロシージャを含むデータベースがあります。その多くは、コードの「早い段階」で #TEMP テーブルを作成する手法を使用し、その後、さまざまな内部ストアド プロシージャがこの親 sProc によって実行されます。SQL2000 では、内部または「子」sProc は #TEMP への INSERT や #TEMP からのデータの選択に問題はありません。つまり、同じ接続を使用しているため、すべてこの #TEMP を参照できると思います。

SQL2008 でのテストでは、異なる動作の 2 つの症状が見つかりました。まず、設計時に、新しい "intellisense" 機能は、子 sProc の Management Studio EDIT で、#TEMP が "無効なオブジェクト名" であると不平を言っています。さらに悪いことに、実行時に、呼び出された親 sProc がネストされた子 sProc 内で失敗します。

解決策は、明らかに異なる接続から参照できるグローバル一時テーブルである ##TEMP に変更することであると誰かが提案しました。

これらの sProc が Web アプリケーションから呼び出された場合 (マルチユーザーの問題など)、すべての問題点を追跡するための作業量と、考えられる/可能性のある厄介な影響の両方から、これはあまりにも抜本的な提案のようです。

これは実際に #TEMP (ローカル一時テーブル) に関する SQL2005 または SQL2008 の動作の変更ですか? 2005 年はスキップしましたが、必要な修正を行う前に、なぜこれが発生するのかをより正確に知りたいと思います。ありがとう。

List<T>1000個のアイテムが含まれているとします。

次に、これをこのリストをフィルタリングするメソッドに渡します。さまざまなケース（たとえば、50のList<T>場合があります）を通過すると、最大50のさまざまなLinqWhere()操作が実行される可能性があります。

私はこれをできるだけ早く実行することに興味があります。List<T>したがって、 aが実行されるたびにこれをフィルタリングしたくありませんWhere()。

List<T>基本的に、すべてのフィルターが適用されるまで、の実際の操作を延期するために必要です。

これはコンパイラによってネイティブに行われますか？または、が返されるIEnumerableで.ToList（）を呼び出すときList<T>.Where()、またはXで操作を実行する必要がありますWhere()（X = List.AsQueryable（））？

これが理にかなっていることを願っています。

linq クエリでガベージ コレクションがどのように処理されるかについて質問があります。処理するリクエストのリストが与えられたとします。各リクエストは非常に大量のデータ セットを生成しますが、フィルタが適用されて、リクエストされた各ロードからの重要なデータのみが保持されます。

したがって、フィルター処理された各データ項目が要求されるまで、データ項目ごとにクエリが延期されることがわかっているので、それで問題ありません。しかし、その中間のメモリ集約型の部分は、列挙型が完了するまで持続しますか?

私が望んでいるのは、各データ要素がフィルタリングされた段階を通過するとすぐにガベージコレクションできることです。これにより、リスト全体を処理するのに十分なメモリがあることを確認できます。これは事実ですか、それとも、クエリ全体が終了するまで、中央の列挙型がすべてを保持しますか? もしそうなら、これに対処するlinqの方法はありますか？

注: Process() 関数は、メモリ集約型のデータを生成します...それが私が心配していることです

実行計画から、INバージョンはEXISTSバージョンよりも高速であるように見えます

EXISTS クエリは条件を熱心にチェックするため、より高速であると考えています。IN クエリは直感的に見えますが、最終条件の結果の解決が非常に遅いように感じます。つまり、裏返しに、次の条件がその内部条件の結果を待つ必要があるため、IN の方が遅いと認識しました。

ただし、以下の実行計画を見ると、IN の方が高速です。それはより低いコストを持っています。

私の一部は、IN バージョンを使用したいと考えています。次のメンテナーにとっては簡単で直感的に見えます。以下の実行計画は、EXISTS よりも高速であることを示しているようです。しかし、私の別の部分は、EX​​ISTS の方が速いと感じているため、EXISTS を使用したいと考えていますが、以下の実行計画はその認識と矛盾しているようです。

以下の 2 つのクエリのうち、IN バージョンと EXISTS バージョンのどちらが高速ですか?

バージョン:

存在するバージョン:

これは、私が最終的に使用する最後のクエリ、INバージョンです。IN バージョンと EXISTS バージョンのわずかなパフォーマンスの違いしか認識できません。私は次のメンテナの可読性についてもっと考えているので、INを使用しました

私はRoles以下を引き出そうとしていますIEnumerable<KeyValuePair<int, string>>

私の質問は、この Linq ステートメントの遅延実行に関するものです。この ProjectContact を返すとき、Linq ステートメントはまだ実行されていないと理解しています。誰かがロールにアクセスしようとしたときではなく、このメソッドで実行されるように、このステートメントの実行を強制する方法はありますか? .Count() を呼び出すことでステートメントの実行を強制できると思いますが、もっと良い方法があるはずです。