Core Data / NSTextView 仅在保存后中断
我们有一个 NSTextView 和一些关于其内容的数据保存在核心数据托管对象上下文中。当托管对象上下文保留在内存中时，一切都运行良好。然而，当我们保存它时，我们会得到非常奇怪的获取请求行为。
例如，我们运行一个获取请求，询问 textLocation 小于或等于 15 的所有元素。我们返回的数组中的第一个对象的 textLocation 为 16。
我知道我在这里无法得到明确的答案，因为代码相当复杂。但有人知道这个问题有什么味道吗？
我的想法是，我们在保存后没有得到与 NSTextView 同步的正确 MOC？什么可以改变打破这一点？
谢谢。
We have an NSTextView and some data saved about its contents in a core data Managed object context. Everything works great while the managed object context stays in memory. However when we save it, we get very weird fetch request behaviors.
For example, we run a fetch request that asks for all elements with a textLocation less than or equal to 15. The first object in the array we get back has a textLocation of 16.
I know I can't get a definitive answer here, as the code is fairly complex. But does anyone know what this issue smells of?
My thought is that we are somehow not getting the proper MOC synced with the NSTextView after saving? What could change that breaks this?
Thanks.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
实际上，获得该值的唯一方法是（按照可能性的相反顺序）：
我自己会从 (3) 开始，因为它似乎更常见，并且在您确认没有显示问题之前，您无法诊断其他问题。
Really, the only way to get that is to (in reverse order of likelihood):
I would start with (3) myself because it seems more common and until you confirm you don't have a display problem, you can't diagnose the other problems.
我终于弄清楚发生了什么事。我使用 setPrimitiveValue 设置 textLocation...只是因为我不想触发通知。事实证明这是一个非常糟糕的主意，因为核心数据不知道值已经改变。它仍然认为该值是 15 而不是 16。
让这成为一个教训：永远不要绕过 KVO，除非您在托管对象内部并且知道自己在做什么！
I finally managed to work out what was going on. I was setting textLocation using the setPrimitiveValue... just because I didn't want notifications to fire off. Turns out that's a really bad idea, because Core Data didn't know the value had changed. It still thought the value was 15 instead of 16.
Let this be a lesson: never bypass KVO unless you're INSIDE the managed object and you know what you're doing!