Может ли ошибаться управляемый объект с неуправляемыми свойствами? - PullRequest
2 голосов
/ 20 октября 2010

Документация Core Data говорит, что объекты могут быть неисправны, чтобы сэкономить память при необходимости. Что произойдет, если у вас есть объект, свойство которого не является управляемым свойством?

Например, скажем, у вас есть класс Department, который является подклассом NSManagedObject. У него есть местоположение iVar + accessors. Свойство location не является атрибутом Department; оно не управляется и никогда не сохраняется.

Если у вас есть массив объектов Department или объект Employee, имеющий отношение «один к одному» с Department, возможно ли, чтобы Департамент когда-либо ошибался? Если вы установили Department.location, можете ли вы быть уверены, что местоположение всегда будет там, или возможно, что Департамент выйдет из строя, и тогда вы потеряете значение, сохраненное в местоположении? *

Ответы [ 2 ]

1 голос
/ 20 октября 2010

Департамент все еще может ошибаться, он будет просто повреждать свойства, которые вы описали в своей модели.Обычно описываемая вами ситуация покрыта «временными» свойствами, которые являются свойствами, которые не хранятся в CoreData, однако объектная модель знает о них.

При реализации переходного свойства вы предоставляете хранилище (или вычисления), необходимые для предоставления значения для этого свойства.

В вашем случае совершенно законно предположить, что ваше значение "местоположения" не будет существовать в будущем, поскольку оно будет существовать только до тех пор, покаФактический управляемый объект остается в памяти.Другими словами, любое действие, которое вызывает освобождение управляемого объекта, такое как сброс контекста, сохранение или обновление из уведомления о сохранении, может привести к потере значения (поскольку управляемый объект, к которому он привязан, превращается в сбой или становится недействительным).

1 голос
/ 20 октября 2010

Я бы не стал доверять неуправляемым данным.Даже если это произойдет сейчас, поведение может измениться в будущем.Более того, архитектурно я бы не рекомендовал хранить неуправляемые данные в управляемом объекте вообще.Вам лучше:

  1. Создание управляемых данных, ИЛИ
  2. Создание неуправляемых данных, вычисляемых из управляемых данных, ИЛИ
  3. Создание объекта, который имеетнеуправляемые данные и отдел как ивары.
...