4

アプリの将来の更新を簡素化するために、コアデータモデルのユーザーデータから参照データを分離したいと思います（データベースをクラウドに保存する予定であり、参照データをクラウドに保存する必要がないため）これは私のアプリケーションの一部です）。したがって、フェッチされたプロパティを使用してストア間の関係をコーディングする方法をしばらく探していました。これの実装例は見つかりませんでした。

2つの構成を使用するCoreDataモデルがあります。

  • データモデル構成1：UserData（ユーザーに関連するエンティティ）

  • データモデル構成2：ReferenceData（アプリケーション自体に関連するエンティティ）

両方の構成に2つの異なるSQLite永続ストアを設定しました。

  • UserData構成（およびストア）にエンティティ「User」が含まれています

  • ReferenceData構成（およびストア）には、エンティティ「Type」および「Item」が含まれています。

以下のように、2つの一方向の弱い関係を作成したいと思います。

  • 「ユーザー」には固有の「タイプ」があります

  • 「ユーザー」には多くの「アイテム」があります

これが私の質問です：

  • プロパティを設定するにはどうすればよいですか？

  • リレーションごとに2つのプロパティが必要ですか（1つは一意のIDを保存するためのもので、もう1つはフェッチした結果にアクセスするためのものです）。

  • この弱い関係を注文することはできますか？

  • 誰かが私にこれの実装例を教えてもらえますか？

マーカスの答えに続くものとして：

フォーラムとドキュメントを見ると、objectIDの代わりにエンティティインスタンスのURI表現を使用する必要があることがわかりました。この背後にある理由は何ですか？

// Get the URI of my object to reference 
NSURL * uriObjectB [[myObjectB objectID] URIRepresentation];

次に、オブジェクトBのURI（NSURL）を親オブジェクトAに弱い関係として保存するにはどうすればよいでしょうか。どの属性タイプを使用する必要がありますか？これを変換するにはどうすればよいですか？アーカイブについて聞いた...？

次に、後で同じ方法で管理対象オブジェクトを取得し（URIRepresentationを変換解除/アーカイブ解除することにより）、URIからオブジェクトを取得する必要があります

// Get the Object ID from the URI 
NSManagedObjectID* idObjectB = [storeCoordinator managedObjectIDForURIRepresentation:[[myManagedObject objectID] URIRepresentation]];

// Get the Managed Object for the idOjectB ...

最後になりましたが、shouIdは、エンティティAで2つのプロパティを宣言します。1つはURIのニーズを永続化するためのもので、もう1つは直接オブジェクトBを取得するためのものですか。

NSURL * uriObjectB [objectA uriObjectB];

ObjectB * myObjectB = [objectA objectB];

あなたが読むことができるように、私は本当に弱い関係を実装するためのいくつかの簡単な例を見逃しています！助けていただければ幸いです。

4

2 に答える 2

6

データを分割することは、断然正しい答えです。参照データはクラウドと同期しないでください。特に、iCloud には、アプリケーションが同期してドキュメントに保存できるデータにソフト キャップがあるためです。

ストア全体でソフト参照を作成するには (SQLite である必要はありませんが、一般的なアプリのパフォーマンスのためには良い考えです)、反対側から参照できる何らかの一意のキーが必要です。古き良き外部キー。

そこから、フェッチされたプロパティをモデルに作成して、エンティティを参照できます。

この関係を直接並べることはできませんが、並べ替えインデックスを使用して順序を作成するか、論理並べ替えがある場合は、データを取得した後で並べ替えることができます (セットではなく並べ替えられた配列を返す便利なメソッドを使用します)。

私は例を作ることができますが、あなたは本当に正しい軌道に乗っています. 唯一の楽しい部分は移行です。移行状況を検出したら、コア データ スタックを構築する前に、各ストアを個別に移行する必要があります。難しそうに聞こえますが、実際に達成するのはそれほど難しくありません。

例

ユーザー ストアに UserBar エンティティがあり、参照ストアに RefBar エンティティがあるとします。RefBar には、UserBar との fetchedProperty "関係" があり、それによって ToOne 関係が作成されます。

UserBar
----------
refBarID : NSInteger

RefBar
--------
identifier : NSInteger

次に、次の述語を使用して、モデラーの RefBar エンティティにフェッチされたプロパティを作成できます。

$FETCHED_PROPERTY.refBarID == 識別子

述語「userBarFetched」に名前を付けましょう

これで配列が返されるので、RefBar に便利なメソッドを追加します。

@class UserBar;

@interface RefBar : NSManagedObject

- (UserBar*)userBar;

@end

@implementation RefBar

- (UserBar*)userBar
{
    NSArray *fetched = [self valueForKey:@"userBarFetched"];
    return [fetched lastObject];
}

@end

ToMany を作成する方法は同じですが、便利なメソッドが配列を返し、それを返す前に配列を並べ替えます。

Heath Bordersが述べたように、必要に応じて並べ替えを追加することは可能NSFetchedPropertyですが、コードで行う必要があります。個人的には、私はいつもそれが無駄だと思っていて、その機能を使用していません. モデラーでソートを設定できればもっと便利かもしれません。

ObjectID の使用

ObjectID または URIRepresentation の使用はお勧めしません。ObjectID (したがって、その ObjectID の URIRepresentation) は変更される可能性があり、変更される予定です。データベースを移行するたびに、その値が変わります。変更されない GUID を作成する方がはるかに優れています。

弱い関係

リレーションシップの M 側に必要な値は 1 つだけで、外部識別子が格納されます。オブジェクトのサブクラスでは、オブジェクト (またはオブジェクト) を取得するアクセサーを実装するだけで済みます。

于 2011-11-21T19:56:05.440 に答える
-2

1店舗だけで行きます。

クラウドにデータを保存するには、JSON ステートメント、SQL ステートメント、または任意のスキームとしてデータをシリアル化する必要があります。

ユーザーのデバイスにデータのローカル コピーが必要です。これにより、ユーザーはすばやくオフラインでアクセスできるようになります。クラウド ストアはユーザー エンティティのみを持つことができますが、ローカル ストア (アプリの一部) も参照エンティティを持つことができます。

地理情報を含む巨大な参照ストア (20000 レコード) とユーザー生成コンテンツ (「投稿」) を含む同様のプロジェクトがあります。単身店舗を利用しています。アプリを出荷すると、「posts」エンティティも定義されていますが空です。データ モデルを更新するときは、出荷前にリファレンス ストア全体を再生成するだけです。

ここでクロスストアソリューションを採用する理由はまったくありません.

于 2011-11-21T16:40:10.787 に答える