NSFetchRequest 具有一对一关系属性 == YES 谓词错误地获取每个实体

Posted 2023-03-04

【中文标题】NSFetchRequest 具有一对一关系属性 == YES 谓词错误地获取每个实体

【英文标题】：NSFetchRequest with to-one relationship attribute == YES predicate incorrectly fetches every entity

【发布时间】：2014-04-11 23:53:33

【问题描述】：

我有一个名为“IRCSessionEntry”的模型实体，它与一个名为“source”的实体具有一对一的关系，该实体具有名为“isSelected”的布尔属性。

当我执行以下获取请求时：

NSPredicate *sourceIsSelectedPredicate = [NSPredicate predicateWithFormat:@"source.isSelected == YES"];
NSFetchRequest *selectedDataSourcesFetchRequest = [NSFetchRequest fetchRequestWithEntityName:@"IRCSessionEntry"];
selectedDataSourcesFetchRequest.predicate = sourceIsSelectedPredicate;
NSSortDescriptor *descendingStartDateSortDescriptor = [NSSortDescriptor sortDescriptorWithKey:@"startDate" ascending:NO];
selectedDataSourcesFetchRequest.sortDescriptors = @[descendingStartDateSortDescriptor];

结果错误地包括每个 IRCSessionEntry，无论它们的源isSelected是否为YES：

Fetched sessionEntry: source Foo isSelected = 1
Fetched sessionEntry: source Foo isSelected = 1
Fetched sessionEntry: source Bar isSelected = 0
Fetched sessionEntry: source Bar isSelected = 0
Fetched sessionEntry: source Bar isSelected = 0
Fetched sessionEntry: source Bar isSelected = 0

我在测试一对一关系上的布尔属性值的语法是否错误？如果是这样，有人可以告诉我如何写这个谓词吗？

如果没有，还有其他人有这个问题吗？

我正在使用 ios 7.1 SDK 运行刚刚发布的 Xcode 5.1.1。

谢谢！

卡尔

P.S.：附加信息：“源”实体也有一个字符串“名称”属性；当我将一对一关系谓词格式字符串更改为

[NSPredicate predicateWithFormat:@"source.name == %@", @"Foo"]

仅正确提取 source.name 为“Foo”的实体。所以在我看来，要么：

1) 我的一对一关系的布尔属性值谓词的语法错误；或者 2) 在 iOS 7(.1) 中，一对一关系的布尔属性值谓词出现了问题。

【问题讨论】：

***.com/questions/7209941/… 的可能重复项

嗯，不是真的，不。我的问题是关于关系的属性（引用的帖子仅涉及实体自己的属性）；此外，不起作用的测试是“== YES”，而不是“== NO”。

可能按照***.com/questions/7064072/… 使用任何或全部？

好吧，既然“源”是一对一的关系（不是对多的），ANY 和 ALL 充其量是多余的。但我试过了，提取的行为完全一样。不过感谢您的建议！

我什么也没看到，我想您只是尝试将其与 1 进行比较。我所能想到的就是设置一个断点并检查获取结果以查看 source.isSelected 实际包含的内容每一行，并确保它是你所期望的......

【参考方案1】：

好的，我知道发生了什么（应该早点想到）。事实证明，这种行为是由于竞争条件造成的。即使关系的“source.isSelected”属性正在主线程上切换，即使我应该获取新的一组选定源的 fetch 也在主线程上执行，但由于某种原因，更改在执行 fetch 之前，“source.isSelected”中的内容尚未传播。换句话说：竞争条件。如果我在执行提取之前插入上下文保存，则一切正常。

所以我将看看我是否无法弄清楚如何以不同的方式管理 change-then-fetch 过程，从而避免在执行 fetch 之前进行完整的上下文保存。无论如何，至少现在它是有某种意义的！

我将保留此查询，以防其他人遇到类似情况，这将为他们提供答案！

再次感谢 RobP 给予这么多思考！

卡尔