9

この質問の形式がこのサイトに適しているかどうかはよくわかりません。

基本的に、永続ストアにデータを保存するたびに NSManagedObjectID が変更されるという設計上の決定を Apple が行うようになった理由を知っている人はいますか?

私は間違っているかもしれませんが、その決定は私には非常に疑わしいように思えます. 明確な利点はありません (UUID です!一意です!) が、objectID を渡すことができます --- オブジェクトが保存されると、いつでも変更できます。

私は 3 つの MOC システム (バックグラウンド MOC -> UI MOC -> Persistent MOC) を使用しているため、これは私にとって大きな問題です。オブジェクトはバックグラウンド MOC に挿入され、保存によって上方に伝播されます。保存は非同期です。3 つの異なる MOC に渡って伝播し、作成後にオブジェクトを返す必要があるためです。ただし、オブジェクト ID を渡すことに依存できないため、永続ストアに保存する前は非常に苦痛です。

私は特に間違ったことをしていますか？通知なしでいつでも変更できる UUID の利点を知っている人はいますか?

私の最大の疑問は、なぜ一時的な managedObjectID が提供されるのかということです。それには何か意味がありますか？人々を混乱させて使おうとするだけですか？

4

2 に答える 2

11

NSManagedObjectIDが特にUUIDであるとあなたが言い続ける理由に少し混乱しています。URI 表現は UUID 形式に似た外観を持っているかもしれませんが、ドキュメントのどこにも「aNSManagedObjectIDは UUID です」と書かれているのは見当たりません (以下で説明するように、それ以上のものです)。Apple が正確にこのように設計した理由は、StackOverflow の範囲を超えているため、「Core Data の設計とは何か、どうすればそれを操作できるのか」という質問が本当にあることを願っています。

ドキュメントで (管理対象オブジェクト ID と URIで) 述べられていることは、この種のオブジェクト追跡を行いたい場合は、独自の UUID をプロパティとして追加する必要があるということです。

新しく挿入されたオブジェクトに対して定義および設定できる独自の一意の ID (UUID) プロパティを作成すると、利点が得られる場合があります。これにより、述語を使用して特定のオブジェクトを効率的に見つけることができます (ただし、保存操作の前には、新しいオブジェクトは元のコンテキストでしか見つかりません)。

NSManagedObjectID不変のデータ構造から変更が見られる理由。プロパティが含まれていpersistentStoreます。これは、オブジェクトを実際に保存するまで確実に知ることはできません (assignObject:toPersistentStore:たとえば、呼び出すことができます)。NSManagedObjectID繰り返しますが、URI 表現の観点から を考えないでください。それは単なるシリアル化形式です。ドキュメントに示されているように、実際の ID には永続ストアが含まれます。

データベースの主キーと同様に、識別子には永続ストア内のオブジェクトを正確に記述するために必要な情報が含まれていますが、詳細情報は公開されていません。

その識別子は、オブジェクトが挿入されるまで確定できません。

于 2013-06-17T03:20:11.813 に答える
5

私は決して Core Data の専門家ではありませんが、ほとんどの状況NSManagedObjectIDで一意であることが保証されていることを理解しています。例外は次のとおりです。

  • 新しいオブジェクトを作成してもまだコミットされていない場合、その ID は一時的なものになります。この状態は で確認できますisTemporaryId。
  • バッキング ストアが変更された場合。つまり、iCloud を使用していて、新しいバージョンのデータベースに移行した場合。

単一のライフサイクルについて話しているので、最初のオプションを見ていると思います。その場合は、変更が永続ストアに反映されるまで ID を取得するのを待つ必要があります。同じオブジェクトからIDを取得できると思います。つまり、オブジェクトを作成し、それへのポインターを保持し、コンテキストを保存してから、保持されたポインターからそのオブジェクトのIDを取得します。警告: 私は実際にこれを行ったことはありません。これは、ドキュメントを読んだことに基づく私の結論です。

また、一時 ID はコンテキストを保存するまで保持される必要があるため、これについて心配する必要があるのは、新しいオブジェクトのコンテキストが最初に保存された後の 1 回だけです。

ちなみに、CoreDataはこのように実装する必要があるように思えます。実際に永続ストアに挿入する前に ID が一意であることを保証しようとした場合、コミットする前に 2 つの異なるコンテキストが同じ ID を取得するとどうなるでしょうか? 一意性を保証し、ID の一種の競合状態を防止する唯一の方法は、レコードをデータベースに挿入するときに一意の ID を見つけることです。それ以外の場合、CoreData は、子コンテキストが挿入する各レコードに対して何らかの方法でダミー値を挿入する必要があります。 ..

于 2013-06-14T15:38:37.867 に答える