coredata谓词可以查询第三级对象吗
我正在尝试做一些更复杂的核心数据查询，但收效甚微。
到目前为止，我已经成功地完成了这项工作：
events.@count != 0
但是后来我尝试了这个（为了测试依赖项是否存在），
events.event.dependents.@count !=0
events.dependents.@count !=0
并出现“不支持的函数表达式计数：(events.event.dependents)”错误。
我理想中想做的是：
ANY events.event.dependents.dependent.dependentId == 13500
ANY events.dependents.dependentId == 13500
我希望我拥有 SQL 的力量（我更熟悉）:(
谢谢
I am trying to do some more complicated coredata queries with little success.
So far I have got this working successfully:
events.@count != 0
But then I have tried this (in order to test dependents exist)
events.event.dependents.@count !=0
events.dependents.@count !=0
With a "Unsupported function expression count:(events.event.dependents)" error.
What I am ideally trying to do is:
ANY events.event.dependents.dependent.dependentId == 13500
ANY events.dependents.dependentId == 13500
I wish I had the power of SQL (which Im more familiar with) :(
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
集合运算符无法将一对多关系横穿到键路径中的另一个键。在这种情况下，按照惯例，事件将是 to_many 关系，因此我认为集合运算符对此感到窒息。
对于 SQL 技术熟练但对 Core Data 不熟悉的人来说，您犯的错误很常见。您试图将 Core Data 只是视为 SQL 包装器，并试图将其硬塞到 SQL 设计模式中。不要那样做。
你这里的问题是你正在倒退地处理问题。由于 Core Data 是一个对象图，因此最常见的模式是执行提取来查找拥有要测试的属性的特定对象，并遍历这些对象的关系以查找相关对象。
因此，在这种情况下，您应该对具有
dependentID属性的实体执行提取。这将返回一个或多个对象（在本例中大概是一个。）然后要找到相关对象，您将从现在的方式向后遍历键路径。因此：dependent.dependents.event.events如果不知道您的数据模型是什么样子，就很难进行更具描述性的操作，但您已经明白了。
在 SQL 中，尽管它是一个关系系统，但与 Core Data 中的使用相比，关系相对较弱。在 SQL 中，您可以在获取代码中生成关系。在 Core Data 中，它们在创建对象时被编码到对象图中。这意味着您查找持久数据所需的工作要少得多。抓取只是从巨大的织物中拔出一根（或少量）线，让您可以通过拉扯关系来解开整个事物。
A collection operator cannot transverse a to-many relationship to another key in a keypath. In this case,
eventsby convention would be a to_many relationship so I presume the collection operator is choking on that.You're making a mistake very common to those skilled at SQL but new to Core Data. Your trying to treat Core Data as just an SQL wrapper and trying to shoehorn it a SQL design pattern. Don't do that.
You're problem here is that you are approaching the problem backwards. Because Core Data is an object graph, the most common pattern is to perform a fetch to find a specific object that possess the attribute you want to test against and the walk those object's relationships to find related objects.
So, in this case, you should perform a fetch against the entity that has the
dependentIDattribute. That will return one or more objects (presumably one in this case.) Then to find the related objects you would walk the keypath backwards from the way you have it now. So:dependent.dependents.event.eventsIt's hard to be more descriptive without knowing what your data model looks like but you get the idea.
In SQL, despite it being a relational system, relationships are relatively weak compared to their use in Core Data. In SQL, you produce relationships in the fetch code. In Core Data, they are encoded into the object graph when the objects are created. That means you have to do far less work find persisted data. A fetch just plucks one (or a small number) of threads from a vast fabric that let you unweave the entire thing by tugging on the relationships.