Добавление атрибута к сущности в Core Data

Question

Я создал все свои управляемые объекты после сопоставления всех сущностей / атрибутов / отношений в модели данных. Теперь у меня проблема с необходимостью добавить дополнительные атрибуты / отношения, о которых я не думал, когда впервые проектировал один из моих объектов / классов. Есть ли способ изменить мой существующий класс NSManagedObject с помощью Core Data, если только не стереть все мои модели и заново создать их на основе нового xcdatamodel?

Будет ли добавление атрибута в xcdatamodel также обновлять механизм хранения? Скажите, если я буду использовать SQLite3 в качестве постоянного хранилища, добавит ли он соответствующий столбец?

Answer 1

Как отмечает сурок, для сложных изменений в вашей модели данных вам нужно будет создать версии вашей модели и перенести данные из старой модели в новую, следуя руководству Apple по этому вопросу (на которое он ссылается). Не беспокойтесь ни о каком закулисном SQL, Core Data справится с этим.

Однако для простых изменений модели данных Apple представила в iPhone OS 3.0 новую функцию Core Data под названием облегченная миграция . Для облегченной миграции Базовые данные будут автоматически мигрировать через простые изменения в вашей модели данных, такие как изменение имени атрибута или объекта, удаление атрибута, добавление атрибута со значением по умолчанию или изменение наследования объекта. Вам просто нужно ввести идентификатор переименования в новой версии, чтобы указать что-то на имя более старой версии и т. Д. Core Data будет эффективно обрабатывать обновления ваших данных, если вы установите параметры NSMigratePersistentStoresAutomaticsOption и NSInferMappingModelAutomaticsOption для ваш постоянный магазин.

Answer 2

Если вы имеете в виду «могу ли я изменить свой xcdatamodel и просто объединить изменения из сгенерированного кода в существующий код для производных классов NSManagedObject», да, это просто. Вы просто генерируете код для моделей, которые изменились, затем объединяете изменения вручную в эти конкретные производные классы. Поскольку изменения звучат так, будто они являются просто дополнительными атрибутами и связями, это должно быть тривиально - на самом деле, вы можете использовать diff и patch, чтобы сделать это полуавтоматически, если ваши изменения действительно аддитивны по своей природе.

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

Прежде чем вы решите приступить к изменению схемы, вы всегда должны прочитать о том, как выполнить миграцию и управление версиями в Базовых данных - если у вас есть существующие хранилища, вам необходимо сохранить. Это почти наверняка имеет место в приложениях, в которых пользовательские данные хранятся в основных хранилищах данных. И если у вас нет автоматизированного инструмента импорта или утилиты генерации хранилища данных, ваши существующие статические хранилища также могут нуждаться в миграции.

Answer 3

Вы также должны проверить шаблоны проектирования Generation Gap. Это поможет вам именно в этой ситуации. Здесь это SO вопрос об использовании разрыва в поколении с CoreData.