Глубокая копия подклассов NSManagedObject с циклами - PullRequest
1 голос
/ 07 июня 2011

Я хочу иметь возможность правильно глубоко копировать объект, который является подклассом NSManagedObject.

Сильно упрощенная версия моей модели данных: «родительские» объекты, каждый из которых ссылается (от 1 до многих)несколько «дочерних» объектов, каждый из которых ссылается (многие на многие) на несколько «меточных» объектов.Все объекты являются пользовательскими подклассами NSManagedObject.

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

НетОбъекты 'child' или 'label' совместно используются более чем одним 'parent'.

Таким образом, у каждого «parent» есть несколько «children» и несколько «label», у каждого «child» есть один «parent»и несколько «меток», каждая «метка» имеет одного «родителя» и несколько «потомков».

Я хочу иметь возможность глубокого копирования «родительских» объектов, поддерживая все дерево объектов, но я нене знает, как разрешить цикл «parent»> «child»> «label»> «parent»… и т. д.

Если при копировании «parent» я копирую все связанные с ним «дочерние» объектыво-первых, и эти «дочерние» объекты копируют свои ссылочные «метки», а также добавляют их в этот «дочерний»«родительский» список «меток», тогда как мне учитывать те «метки», которые должны быть в «родительском» списке «меток», на которые не ссылается ни один «потомок».Если я объединю копию оригинального списка «родительских» меток в новый, я получу список с «метками» из «дочерних» объектов (хочу), а также любые свободные «метки», не связанные с'child' (do want), а также копии «меток», которые были связаны со старыми объектами child'а родителя (не хотите).

И наоборот, если я скопирую метку «родительские ссылки»сначала «объекты», затем они не могут быть связаны с «дочерними» объектами, какими они должны быть, потому что «дочерние» объекты еще не существуют.

Aaaargh!

Если это звучит ввсе сбивает с толку, это потому что это так.По крайней мере, это меня смущает.

1 Ответ

0 голосов
/ 09 июня 2011

Это нетривиально, но было решено несколько в других вопросах. Надеюсь, люди могут придумать более простые ответы. См .: Как сделать Deep Copy NSManagedObject в Core Data

РЕДАКТИРОВАТЬ: Одна из стратегий заключается в использовании метаданных отношений для циклических ссылок, вызванных родителем / ребенком. Из объекта NSManagedObject получите объекты NSRelationshipDescription и проверьте обратные отношения.

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

...