問題タブ [identity-map]

DataTable はメモリを大量に消費しますが、取得時間が O(1) であるため、オブジェクトのセットが非常に大きい場合、実装するのに DataTable と IdentityMap が最適ではないでしょうか?

アップデート

IDictionary を使用することにした場合、オブジェクトを取得するときに速度を犠牲にしますか?

Datamapper の要素を持つ優れた PHP ORM を使用する必要がありますが、私はそれを自分でコーディングするほど賢くありません。

教義を選択しましたが、ユーザーガイドを読んだ後、アイデンティティマップを使用してデータベースへの呼び出しを減らす方法を示すものは何も見つかりません。

ドクトリンORMでアイデンティティマップを作成する方法を教えてください。

データマッパー、アクティブレコード、ID マップ、ドメイン モデルなどを昨日ファウラーの PEAA ブックで読んで理解しました。

DataContextが実際にどのくらいの期間存続する必要があるのか​​疑問に思っていました。DinoEspositoのMicrosoft.NET：Architecting Applications for the Enterpriseのようなすべてのパターンと実践の本は、データコンテキストが長く存続してはならず、キャッシュされてはならないことを示しています。しかし、適切な時期はどのくらいですか？Webリクエスト全体、作業単位、トランザクション、一度に1つのクエリのみ？（通常、Webリクエストには複数の作業単位があると思います）

EntityFrameworkをWebアプリケーションのORMツールとして使用するとします。しかし、このシナリオのIDマップパターンはどうでしょうか。Datacontextを作成するCustomerDALの専用インスタンスと、その目的のために新しいDataContextを自分で作成する別のInvoiceDALがあるとします。すべてのDALの基本クラスを取得した場合、ObjectContextの単一のインスタンスが作成され、最後にこれが破棄されます。それは悪い実装と見なされますか？私の意見では、1つのWebリクエストに対して1つのObjectContextを使用することは理にかなっています。EntityFrameworkでサポートされているIDマップパターンを1つの利点として利用できます。

アイデア、コメント、考え、批判はありますか？

特定の主キーを持つオブジェクトがすでにDataContextにアタッチされているかどうかを確認し、アタッチされている場合はDataContextからエンティティを取得する必要があります。完全な信頼を持ってReflectionを必要としないこれを行う方法はありますか？

理想的には、GetCachedObject（）を呼び出したいのですが、それを取得するにはリフレクションを使用する必要があり、ホストされた環境では機能しない完全信頼モードである必要があると確信しています。 。

私はここで箱の外で考えることにオープンです。また、生成されたLinqToSqlコードを完全に制御できるので、それも問題ではありません。DataContextクラスを書き直すことができます。IdentityManagerにアクセスしたり、IdentityManagerを独自の抽象化に置き換えたりする方法はありますか？どんなアイデアでも大歓迎です。

NHibernateを使用して、私は通常、Get（）またはLoad（）メソッドを使用して単一のレコードを照会します（プロキシが必要かどうかによって異なります）。

ここで、以下の例のように、このステートメントを2回実行すると、単体テストで実行されているクエリは1つだけになります。

ここまでは順調ですね。しかし、ICriteriaクエリを使用して同じオブジェクトを取得すると、奇妙な動作に気づきました。以下のコードを確認してください。最初のオブジェクトインスタンスを取得します。次に、プロパティの値を10（データベースの値は8）に変更し、別のインスタンスを取得して、最後に2番目のオブジェクトインスタンスの値を確認します。

新しいクエリでオブジェクトを要求したにもかかわらず、値がobj2の10であるため、何らかの理由でアサートが失敗します。面白いことに、ユニットテストの出力ウィンドウに従って実行されているまったく同じselectクエリが2つあります。私の質問：2番目のオブジェクトが第1レベルのキャッシュからフェッチされた場合、なぜ2つのクエリが実行されるのですか？

私は何かが足りないのですか、それともこれはバグですか？

よろしく、テッド

編集＃1：NHibernate v2.1.2GAの使用編集＃2：実行されている2つのクエリに関する説明を最後の段落に追加しました。

long型の複数のフィールドを許可するものを見つけました。ただし、たとえばGuidや日付さえある場合があるため、それがどれほど役立つかはわかりません。

私のニーズをサポートするために彼を変更することもできますが、これは非常に一般的な要求であるため、最初から作成するのではなく、テストされ、試行され、真実であるものを見つけることができるはずです。

この背後にある主な目的は、IDマップパターンを使用することです。このパターンは、多かれ少なかれ、それをサポートするためにIDフィールドパターンを必要とすると思います。辞書のキーとしてIdentityFieldコンストラクトを使用します

何か案は？

ありがとう

ID マップと作業単位パターンは、sqlalchemy が django.db よりもはるかに魅力的である理由の一部です。ただし、ID マップがどのように機能するか、またはアプリケーションが wsgi として構成されていて、orm が共有サービスではなく API 呼び出しを介して直接アクセスされる場合に機能するかどうかはわかりません。apache は、リクエストごとに独自の Python インスタンスを持つ新しいスレッドを作成すると思います。したがって、各インスタンスは sqlalchemy クラスの独自のインスタンスを持ち、ID マップを利用できなくなります。これは正しいです？

特にAndroidの場合、Hibernateの軽量な代替品について多くの質問がありました。しかし、そのうちのどれが「アイデンティティマップ」パターンを持っていますか？

このパターンにより、データベース内の行を表すオブジェクトがセッションに1回だけ存在するようになります。–プログラムの一貫性を保つのに役立ちます。マップされたオブジェクトをどこかで変更すると、どこでも変更されます（すべての参照が同じオブジェクトを指しているため）。新しいデータベースクエリを介してオブジェクトを再フェッチするか、以前の呼び出しからオブジェクトを保持するかは関係ありません。ORMは、すべてが同じように動作することを確認します。

Hibernateは、これを「レベル1キャッシュ」で実行します。

Rails 3.1 IdentityMap機能がデフォルトで機能を無効にすることを余儀なくされている重要な問題を知っている人はいますか？マイナーな特定の問題があると確信していますが、すでにビルドされているRails 3.1アプリケーションで有効にする前に、誰かが知っておくべき大きな問題はありますか？