objectWithID:与existingObjectWithID之间无法解释的行为差异: [英] unexplained behavioural difference between objectWithID: versus existingObjectWithID:

查看:201
本文介绍了objectWithID:与existingObjectWithID之间无法解释的行为差异:的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我理解这两个调用之间的文档差异。但是没有人知道我注意到的以下观察行为的原因:

I understand the documented differences between these two calls. However does anyone know the reasons for the following observed behaviour I have noticed:

如果我有一个parentContext和临时childContext,我使用childContext编辑,插入和删除对象,如果使用[childContext objectWithID:objectID];要检索存在于父上下文中的已知现有受管对象,它有时会给我一个对象,该对象具有在被触发时失败并生成异常的错误。我理解objectWithID:通过设计,总是返回一个处于故障状态的对象,而不管给定objectID是否存在实际的managedObject。然而,如果对象实际上存在于父上下文中,我期望当访问任何属性时,该对象将总是成功地从父上下文检索(例如,故障将被触发)而没有任何问题。如果我使用[childContext existingObjectWithID:objectID];我发现它确实总是成功。

If I have a parentContext and a temporary childContext where I use the childContext to edit, insert and deleted objects, if use [childContext objectWithID:objectID]; to retrieve a known existing managed object, present in the parent context, it will sometimes give me an object with a fault that on being fired fails and generates an exception. I understand objectWithID: will, by design, always return an object in a faulted state regardless of if an actual managedObject exists for the given objectID. However if the object actually exists in the parent context, I would expect that when any of the properties are accessed, the object will always be successfully retrieved from the parent context (e.g. the fault will be fired) without any problem. If I use [childContext existingObjectWithID:objectID]; I find it does indeed always succeed.

对于记录,我已关闭子上下文的缓存,并且在调用[childContext resetContext]之后也会出现相同的行为 - 因此它不是旧缓存的文件与父上下文不一致的数据。

For the record, I have turned off caching on the child context and this same behaviour occurs after [childContext resetContext] has been called - so it's not an artefact of old cached data hanging around that is inconsistent with the parent context.

文档本身似乎不足以解释这种行为。我当然可以粉碎它的经验,只是说我现在知道总是使用existingObjectWithID:当传递对象ID到我的孩子编辑上下文执行块,但我感到不安,并希望了解这里正在发生什么最少所以我可以理解,如果使用一个作为超过其他的任何性能影响,但也要了解约束是什么,所以我可以确保没有一些坏的做法我不必要的实现在我的代码,然后使用错误或无效的调用来修复它)。

The documentation alone seems to me to be insufficient to explain this behaviour. I can of course chalk it up to experience and just say "I now know to always use existingObjectWithID: when passing object IDs to my child edit context perform block" but I feel uneasy and would like to understand exactly what is going on here (not least so I can understand if there is any performance impact of using the one as over the other but also to understand what the constraint is so I can ensure there isn't some bad practice I'm unnecessarily implementing in my code and then using a wrong or inefficient call to fix it).

推荐答案

有与OP相同的问题,设计为

Having the same issue as the OP, and while I think the exception is by design as per


如果对象未在上下文中注册,则可能会被抓取或作为故障返回。此方法总是返回一个对象。由objectID表示的持久性存储中的数据假定为存在 - 如果不存在,则在访问任何属性(即触发故障时)时返回的对象将引发异常。这种行为的好处是,它允许您创建和使用故障,然后在后面或单独的上下文中创建基础数据。

If the object is not registered in the context, it may be fetched or returned as a fault. This method always returns an object. The data in the persistent store represented by objectID is assumed to exist—if it does not, the returned object throws an exception when you access any property (that is, when the fault is fired). The benefit of this behavior is that it allows you to create and use faults, then create the underlying data later or in a separate context.

在苹果文档 - 也就是说,数据不是在持久存储中,它是坐在父上下文 - 它仍然似乎奇怪,我根本不能在父上下文中获得我的已实现的对象。为什么持久存储必须知道它,为了我的对象被填充?

in the Apple docs -- that is, the data is NOT in the persistent store yet, it's sitting in the parent context -- it still seems odd that I simply cannot get my realized object in the parent context. Why must the persistent store have to know about it, for my object to be populated?

这篇关于objectWithID:与existingObjectWithID之间无法解释的行为差异:的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆