【问题标题】:Using Cascade Delete Rule and validateForDelete on a One-to-Many Relationship in iPhone Core Data在 iPhone Core Data 中的一对多关系上使用级联删除规则和 validateForDelete
【发布时间】:2011-01-20 14:00:01
【问题描述】:

前言:

我有两个实体定义为一对多关系:A B. B 与 A 的关系称为 myAs 并且是与 Nullify 作为删除规则的一对多关系. A 到 B 的反比关系是一对一的关系,Cascade 作为删除规则。

我已经在 B 类上实现了 validateForDelete,如下所示:

- (BOOL)validateForDelete:(NSError **)error {
    [super validateForDelete:error];
    BOOL validDelete = FALSE;

    if ([self.myAs count] == 0) {
        validDelete = TRUE;
    }

    return validDelete;
}

这样做的目的是仅在不再有 A 对象与其建立关系时才删除对象 B(但如果不再有任何 A 对象与其建立关系,则始终删除 B 对象)。如果我在保存之前手动检查此验证,则此 validateForDelete 按预期工作:在 B 对象删除时:

if ([b validateForDelete:NULL]) {
    //delete b object...
    [context save:&error];
    ...
}

我遇到的问题是当 B 对象的删除与 A 对象的删除级联时。用户将无法直接访问 B 对象——它们是通过 A 对象创建和删除的。因此,我的规则是,当没有更多与之关联的 A 对象时,B 对象将被删除,必须从 A 对象强制执行 - 因此删除时的级联。

问题是当我删除一个 A 对象时,由于级联,对 B 对象调用了 validateForDelete。我收到一个已解决的错误:未解决的错误 (null), (null),因为我没有手动调用 validateForDelete。

问题:

如何以编程方式从级联删除访问 validateForDelete 调用,以便我可以传入错误变量和/或处理 FALSE 的 validateForDelete 结果?

如果上述情况不可行,我应该如何处理这个用例?还有其他更实用的方法来实现这一点吗?

提前致谢。

【问题讨论】:

    标签: iphone objective-c cocoa-touch core-data


    【解决方案1】:

    首先,您对 super 的调用忽略了它的响应,并且它没有对 super 的响应采取行动。这通常是个坏主意。

    其次,当你对 validateForDelete 说 NO 时,它会抛出异常,因为删除规则无法完成;在这种情况下级联删除。简而言之,验证方法不是尝试处理这种情况的正确位置。

    要处理这种情况,您应该重写 A 类中的 -prepareForDeletion 方法,并让它查看任何适合该情况的 B 并酌情删除它们。您还需要将删除规则更改为无效而不是级联。我将按如下方式实现:

    - (void) prepareForDeletion
    {
      [super prepareForDeletion];
      if (![self myB]) return; //I don't have a B
      if ([[[self myB] myAs] count] > 1) return; //Has more relationships
      [[self managedObjectContext] deleteObject:[self myB]];
    }
    

    这将检查您是否有 B,如果有,则 B 是否有多个关系,如果没有,则将其添加到队列中以进行删除。否则它将允许 Core Data 使关系无效。

    【讨论】:

    • 非常感谢。这正是我所需要的。
    【解决方案2】:

    您想使用“拒绝”删除规则。它仅适用于这种情况。

    【讨论】:

      猜你喜欢
      • 2011-01-13
      • 2012-03-31
      • 2017-06-02
      • 2012-04-15
      • 1970-01-01
      • 2011-09-29
      • 1970-01-01
      • 2012-03-05
      • 1970-01-01
      相关资源
      最近更新 更多