2

date特定のエンティティ B が削除されるたびにプロパティを更新する必要がある Reminder エンティティがあります。削除時に管理対象オブジェクトのサブクラスでいくつかの便利なことを実行できると考えて、コーディングに数日を費やしました。私は試した

- (void)willSave
{
if (self.isDeleted) 
    // use self.managedObjectContext
}

コンテキストはゼロでした。関係もそこで崩壊しました。けっこうだ。

prepareForDeletionそれで...オブジェクトがまだ削除されていないという事実を回避するために面倒なコードを書き始めましたが、Core Dataは私の顔にself.managedObjectContext == nilをスローします。ドキュメントによると、これは私が「関係が崩壊する前に」行う場所です。それで、アクセス可能でself.managedObjectContext == nilある場合のポイントは何self.relationshipA.managedObjectContextですか(ドキュメントが示唆するように)?さらに重要なことに、まだ削除されていないオブジェクトにコンテキストがないのはなぜですか?

私はここでその問題に関するコメントを読みました

それは「否認」であるほど「障害」ではなく、コンテキストがあなたのオブジェクトを否認したため(彼は削除され、保存はデータベースにコミットされました)、オブジェクトは否認されました。変更中のメソッドに保存しないでください。オブジェクトは、おそらく操作後にコミット/保存する必要があります。– ダン シェリー 5 月 21 日 19:05

私のコードは次のとおりです。

[moc deleteObject:obj]
[moc save:NULL]

保存操作を削除するとself.managedObjectContextprepareForDeletion. つまり、自動保存されるまでは、再び nil になります。おそらく、親コンテキストもそれを削除し、続いて UIManagedDocument によって保存されたためです。

私の唯一のオプションは、カスタム削除メソッドを作成すること (Core Data が削除をカスケードするまで機能し、その場合は呼び出されません)、または NSManagedObjectContextDidSaveNotification をリッスンする新しいクラスを作成することだと考え始めています。

アップデート:

私のコアデータモデル

ユーザーは、ある人と連絡を取り合いたいと考えており、連絡がなかった場合に一定の間隔 (ContactWish に保存されている) の後に思い出させたいと考えています。私が達成しようとしているのは、特定の人の最新の ContactOccasion が削除されると、対応する機会->人->希望->リマインダーが(間隔を使用して)更新されることです。

これは私にとって学習経験であるため、コード内のすべての場所から手動で更新を呼び出すだけでなく、正しい方法 (カスケード削除などで機能する方法) を見つけたいと思っていました[MOContext deleteObject:occasion]。提案は大歓迎です。

(リマインダー エンティティも、より手動で使用できるように準備されています)

4

1 に答える 1

1

Reminderエンティティにその日付プロパティを管理させる方がはるかに論理的ではないでしょうか? changedValues:関係エンティティが削除されるのを(おそらく 経由で) "リッスン"し、更新を実行できます。

Bエンティティはエンティティの更新のロジックに実際に関心を持つべきではないため、これはより一貫しているように見えReminderます。

以下の議論に従って編集
し、データベースカスケード削除モデルを更新ロジックでロードしすぎることはできないという私の意見に基づいています。

削除に反応するのではなく、変更を行うために設定してリッスンする属性を導入できます。

このロジックを処理する独自の「deleteOccasion」メソッドを作成するよりも、コア データ削除メカニズムに依存する方が簡単で洗練されているとは思えません。

于 2013-08-04T07:24:44.810 に答える