Пользовательский NSManagedObjectModel для NSPersistentDocument, созданный во время выполнения

У меня есть приложение на основе документов (OS X), которое использует Core Data, поэтому документ является подклассом NSPersistentDocument. Когда пользователь создает документ, он / она указывает параметр, который определяет количество атрибутов, которые имеет конкретная сущность в модели управляемых объектов. Например, сущность «Бейсбол» может иметь от 4 до 9 атрибутов иннинга, в зависимости от того, сколько пользователь указывает при создании документа. В целях повышения эффективности модели управляемых объектов генерируются при создании документа с объектами бейсбольной игры, содержащими точно такое количество заданных атрибутов иннинга. Следовательно, документ с пятью иннингами будет иметь другую модель управляемых объектов, чем документ с девятью иннингами.

Чтобы динамически установить модель управляемых объектов, мне нужно переопределить -(id)managedObjectModel в документе. Это тривиально, и я легко могу создать управляемую объектную модель с нужным количеством иннингов. Однако, если пользователь открывает сохраненный документ (с неизвестным количеством иннингов), меня снова просят передать документу его управляемую объектную модель через -(id)managedObjectModel. Моя загадка: как я могу сказать документу, сколько в нем иннингов, если я сам не знаю? Модель управляемых объектов создается и настраивается во время выполнения, поэтому разумно добавить в документ какое-то свойство, которое сообщает мне, сколько существует иннингов. Я думал о чем-то похожем на NSUserDefaults для каждого документа, но такого не существует. Единственный способ, о котором я могу думать, - это хранить в хранилище любой объект / атрибут, который явно дает мне количество иннингов, но он не будет доступен, пока я не предоставлю документу его управляемую объектную модель! Как правильно это сделать?


person user2105505    schedule 09.08.2014    source источник


Ответы (1)


Фактически, у вас действительно есть что-то вроде документа NSUserDefaults, когда вы используете Core Data, потому что файл постоянного хранилища может сохранять метаданные о файле. Эти метаданные могут быть какими угодно. Доступ к метаданным через постоянный координатор хранилища. Я не использовал NSPersistentDocument, но если URL-адрес не совпадает с URL-адресом документа, похоже, ваш подкласс может сделать что-то вроде self.managedObjectContext.persistentStoreCoordinator.persistentStores, чтобы попасть в правильное место.

Однако я собираюсь добавить, что это звучит как неправильный подход к вашей проблеме. У вас есть игровая сущность, которая связана с несколькими иннингами. Почти в каждом случае правильным ответом будет отношение ко многим от игры к иннингу, а не множественные независимые отношения иннинга. Дайте каждому иннингу целочисленный атрибут, называемый чем-то вроде inningNumber, чтобы вы знали, что есть что, и сделайте так, чтобы логика вашего приложения ограничивала отношение диапазоном [4, 9]. Тогда вы получите все необходимое преимущество экономии места при гораздо меньшей сложности. Как плюс, если в играх когда-либо будет другое количество иннингов (дополнительных иннингов?), Вы можете продолжать использовать ту же модель данных.

person Tom Harrington    schedule 09.08.2014