Сбои в создании Inferred Mapping Model (Облегченная миграция).Проблема с потоками?

Question

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

Вот как я создаю эту модель (конечно, после того, как я создал правильные объекты currentModel и newModel):

NSMappingModel * mappingModel = [NSMappingModel inferredMappingModelForSourceModel: currentModel destinationModel: newModel error: & error];

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

Теперь, вот в чем дело: я запускаю этот метод в другом потоке .Точнее, он находится внутри блока, который передается через GCD для запуска в глобальной главной очереди.Мне нужно сделать это, чтобы мой пользовательский интерфейс казался пользователю четким, т. Е. Чтобы я мог отображать индикатор прогресса во время работы.

Кажется странным то, что если я уберу материал GCD ипросто запустите его в главном потоке, он работает нормально и никогда не падает.Таким образом, может ли это быть из-за того, что я запускаю это в другом потоке, в котором происходит сбой?

Я как-то нахожу это странным, потому что не верю, что нарушаю какие-либо правила Core Data, касающиеся многопоточности.В частности, я не передаю никаких управляемых объектов, и всякий раз, когда мне нужен доступ к MOC, я создаю новый MOC, то есть я не полагаюсь ни на какой MOC (или в этом отношении: что-нибудь ), который был создан ранее в главном потоке.Помимо небольшого происходящего MOC, происходит после метода создания модели отображения, то есть после точки, в которой происходит сбой приложения, поэтому оно не может быть причиной сбоевна рассмотрении здесь.

Все, что я делаю, - это беру двух мам и спрашиваю модель сопоставления между ними.Это не может быть неправильно даже при многопоточности, не так ли?

Есть идеи о том, что может происходить?

Answer 1

В итоге я полностью отказался от этой проблемы и сам создал проклятые модели картографирования.

Answer 2

Во-первых, что такое авария?

Во-вторых, Core Data обычно представляет собой однопоточный API. Есть вещи, которые вы можете делать в нескольких потоках, но создание NSMappingModel, скорее всего, не является одним из них. Почему должен динамически создавать модель отображения? Если MOM являются известной величиной, то сопоставление также может быть известной величиной.

обновление

Во-первых, проблема с потоками. Базовые данные должны быть однопоточными. Однако NSManagedObjectContext знает, как правильно заблокировать NSPersistentStoreCoordinator, поэтому у вас может быть один NSManagedObjectContext на поток, потому что они знают, как правильно блокировать. Однако это не тот случай, когда вы работаете и создаете модель отображения.

Однако указанная вами ошибка не является ошибкой основных данных per se . Эта ошибка означает, что где-то в вашем коде вы пытаетесь вставить ноль в набор. Не видя код, который генерирует модель отображения, хотя трудно догадаться, где именно.

Поставили ли вы точку останова на objc_throw_exception и посмотрите, какая строка в вашем коде вызывает этот сбой? Если это что-то неочевидное, то я хотел бы предположить, что в построении модели отображения есть какой-то момент, который дает Базовым данным неожиданный ноль.

Одна вещь, которую вы можете попробовать, это заблокировать NSPersistentStore и / или NSManagedObjectContext самостоятельно, чтобы посмотреть, разрешит ли это аварию. Однако я подозреваю, что когда вы это сделаете, вы снова столкнетесь с проблемами производительности.