Совместное использование непостоянных объектов между контекстами в базовых данных?

Question

Мне было интересно, есть ли способ разделить NSManagedObject между двумя или более NSManagedObjectContext объектами, работающими в одном потоке.

У меня следующая проблема: у меня один основной контекст, общий для всего моего кода в приложении, и несколько разных контекстов, которые создаются для каждого запроса удаленной выборки, который я выдаю. (Я создал собственный класс, который выбирает удаленно и вставляет все объекты, найденные на сервере, в его NSManagedObjectContext). Эти запросы на выборку могут выполняться одновременно, поскольку они используют NSURLConnection объекты, которые могут заканчиваться в разное время. Если один и тот же удаленный объект выбирается разными подключениями, я получу дубликаты в момент сохранения и объединения контекста с основным. (То есть объекты, имеющие одинаковый удаленный идентификатор, но отличающийся objectID).

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

Я действительно с нетерпением жду метода, который позволит вам совместно использовать один и тот же непостоянный экземпляр объекта в контексте. Если кто-нибудь сталкивался с этой проблемой и нашел решение, я был бы рад узнать!

Answer 1

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

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

Answer 2

Я не думаю, что вы хотите сделать это возможно. Я имею в виду, если вы хотите поделиться изменениями между различными контекстами, вы должны использовать уведомления и объединять их всякий раз, когда происходило сохранение или изменение произошло. Но в вашем случае, я бы сказал, просто используйте 1 контекст и сохраните в конце. Или менее элегантный способ: сохранить все временные идентификаторы удаленных приложений и проверить их перед добавлением новых. В этом случае вы можете продолжать использовать несколько контекстов и сохранять после каждой из них.