Удаление и добавление постоянных хранилищ в основное приложение данных - PullRequest
2 голосов
/ 13 февраля 2010

Я использую основные данные в приложении для iPhone. У меня есть несколько постоянных магазинов, которые я переключаю с одного на другой, так что в данный момент активным может быть только один из них. У меня есть один контекст управляемого объекта, и разные постоянные хранилища похожи по формату данных (sqlite) и используют одну и ту же модель управляемого объекта.

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

*** Terminating app due to uncaught exception 'NSObjectInaccessibleException', reason: 'The NSManagedObject with ID:0x3c14e00 <x-coredata://6D14F11E-2EA7-4141-9BE8-53747DE6FCC6/Book/p2> has been invalidated.'

Эта ошибка возникает из-за сохранения: NSManagedObjectContext. Перед повторным импортом я удаляю постоянное хранилище из координатора постоянного хранилища и удаляю физический файл, поэтому все должно быть так, как будто повторный импорт был выполнен впервые. Алос, объекты в контексте управляемого объекта удаляются, и контексту отправляется сообщение reset: (я не знаю, действительно ли это необходимо).

Может ли кто-нибудь помочь мне здесь? Как следует переключить постоянное хранилище?

Я в основном использую ту же логику, что и здесь: http://blog.sallarp.com/iphone-core-data-uitableview-drill-down/

Заранее спасибо.

Обновленная информация о цели

Спасибо за ваши ответы.

Извиняюсь за неопределенность в моей цели. Я занимаюсь разработкой приложения для чтения Библии, которое будет импортировать переводы из XML в SQL с основными данными. В настоящее время может использоваться только один перевод. В настоящее время у меня есть только разные MOC и PS для каждого перевода, так как модель одна и та же. Однако я верю, если вы скажете, что стек должен быть создан целиком. Переводы не связаны между собой, поэтому нет никакой реальной причины использовать один и тот же стек. Единственное, что может усложнить это, это заметки / закладки / и т.д., которые будут ссылаться на активный перевод. Ссылки, тем не менее, будут текстовыми, поэтому снова нет необходимости в общем стеке.

Спасибо за ваш вклад.

Ответы [ 2 ]

2 голосов
/ 13 февраля 2010

Я согласен с Луи: то, что вы делаете, - это опасный дизайн, и вам следует перестраивать весь стек, а не обменивать магазины таким образом. Восстановление полного стека не требует больших затрат.

Кроме того, если вы используете совершенно разные модели с совершенно разными объектами данных, вам не нужно их удалять, вы можете добавить все модели вместе в одно постоянное хранилище и в зависимости от того, какую сущность вы создаете, Core Data сделает правильная вещь.

Если вы строите несколько моделей с одинаковой сущностью, тогда возникает вопрос почему ? Вы не получите от этого никаких преимуществ в производительности.

Обновление

В описанной вами ситуации я бы поместил все хранилища в один постоянный координатор хранилища, а затем дал указание контексту, в котором хранится сущность, с помощью -assignObject:toPersistentStore:. Это избавит от необходимости создавать и разбирать несколько стеков базовых данных.

Обновление 2

Новый стек - это весь стек. PSC, MOM и MOC. Вы вытаскиваете коврик из-под стека базовых данных и ожидаете, что он просто выяснит, что вы делаете.

Какова ваша конечная цель?

Позднее обновление

Хм, так какой будет приемлемый сценарий для создания только PS и MOC и использования существующих PSC и MOM? Если бы я догадался, я бы сказал, что каждый раз, когда я вносил изменения в существующий стек, он должен создаваться заново и что, если использовалось несколько хранилищ, они должны быть введены во время создания.

NSManagedObjectModel, NSPersistentStoreCoordinator и NSPersistentStore довольно тесно связаны между собой, поэтому неясно, какова ваша цель здесь. Если вы обновите свой вопрос тем, что пытаетесь выполнить, ответы на него станут менее размытыми.

Наличие нескольких экземпляров NSManagedObjectContext обычно используется, когда вы имеете дело с несколькими потоками и несколькими очень редкими крайними случаями. Наличие нескольких экземпляров NSPersistentStore обычно используется, когда у вас есть данные, которые по той или иной причине должны быть скрыты (частично только для чтения и т. Д.). Это нормальные случаи использования.

Хотя мой вопрос остается открытым, чего вы пытаетесь достичь?

Обновление по цели

Я занимаюсь разработкой приложения для чтения Библии, которое импортировало бы переводы из XML в базовые данные SQL. В настоящее время может использоваться только один перевод.

Хорошо, вам не нужны отдельные файлы для каждого перевода, это пустая трата времени. Поскольку каждый перевод идентифицируется кодом (например, ASM) и именем, авторским правом и т. Д., Вы можете просто создать в своем проекте сущность верхнего уровня, которая называется ... «Перевод» и остальные ветви данных оттуда. Никаких множественных контекстов, никаких переключений, просто работает.

Единственное время, когда вам нужно несколько файлов, - это если вы работаете с несколькими документами, а это не то, что вы делаете на iPhone.

1 голос
/ 13 февраля 2010

Это почти наверняка тот случай, когда используемый вами NSManagedObjectContext все еще имеет внутренние ссылки на объект, который поддерживается отдельным постоянным хранилищем. Самый простой способ справиться с этим - не использовать контекст.

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

Создание и уничтожение NSManagedObjectContexts действительно легковесно. Создание полностью нового PSC немного сложнее, но в масштабе того, что вы делаете (перемещение файлов и импорт XML), это, вероятно, также невозможно измерить.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...