Core Data в деталях

[subdan]

Вы пишете:

Классы, наследуемые, от NSManagedObject (таблицы), не имеют «обычного» конструктора, в отличии от остальных классов. Чтобы создать объект типа Company, нужно написать достаточно неповоротливую конструкцию с использованием NSEntityDescription.

Начиная с iOS 10 появилась возможность создать экземпляр NSManagedObject через конструктор указывая только NSManagedObjectContext:
let company = Company(context: persistentContainer.viewContext)

[IrixV]

Спасибо, это очень важное замечание, использовать «конструктор» удобнее и безопаснее, так как не требуется выполнять приведение типов. Уж не знаю, как и почему я упустила эту важную деталь, внесу исправления в статью по вашему комментарию.

[vuvashek]

Спасибо за хорошую статью. Название статьи противоположно содержанию), деталей оч мало, везде совсем по чуть-чуть и нет реальных проблемы из продакшена, например кодогенерация не всегда работает очевидно. Еще было бы оч интересно почитать по утечки памяти при использовании циклических связей. Рекомендую книгу от objc.io Core Data. Там авторы не рекомендуют использовать parent сущности, так как все entities с одинаковым парентом будут хранится в одной таблице, что может привести к performance issues

[IrixV]

У меня не было намерений описывать все детали CoreData. Это невозможно в одной статье. Здесь набор пунктов, «которые я считаю важными или недостаточно освещенными в туториалах».
Про циклические связи я не писала. Инверсия — это не циклическая связь, она обеспечивает внутренний механизм кеширования и докачки данных в CoreData, и никак не меняет связанность таблиц. Если же вы реально используете циклические связи в базе — то это ваше право и ваши проблемы.
Про Parent Entity я не писала, и не рекомендовала их использовать. Это полезная вещь, которая может уменьшить количество кода. Но основная проблема — это усложнение понимания структуры данных. Так что здесь нужно тщательно взвешивать свое решение. Использовать Parent Entity имеет смысл только, если у вас действительно большое количество кода в классе, и, главным образом, много совпадающих полей. Есть также несколько статей, о проблемах с performance при использовании Parent Entity. Я этот момент не проверяла лично, допускаю, что такое возможно. Но в целом, при правильном проектировании базы, выборки из одной или из двух таблиц, или фильтры не должны серьезно влиять на производительность. Даже если у вас миллионы записей в локальной базе (что очень маловероятно), вы вряд ли сможете почувствовать разницу, разбив одну таблицу на две или наоборот.

[vuvashek]

Спасибо за ответ. Циклической я назвал инверсию так как есть два объекта и каждый ссылается на другого, соответственно если Вы используется инверсию, у Вас могут происходить memory leak'и. Об этом есть здесь developer.apple.com/library/archive/documentation/Cocoa/Conceptual/CoreData/MO_Lifecycle.html в разделе Breaking Strong References Between Objects.
Немного не так понял раздел Вашей статьи «Наследование», почему-то подумал что это про parent entity, май бэд.

[IrixV]

В CoreData создание связи между объектами всегда сопровождается созданием инверсии. Поэтому фраза «если вы используете инверсию» аналогична фразе «если вы используете CoreData». Если у вас есть какой-то интересный опыт с CoreData memory management, и вы знаете в каких ситуациях возникают утечки и как этого избежать — напишите отдельную статью или подробный комментарий, будет интересно.