Ошибки основных данных и выборка отношений ко многим

У меня есть несколько «теоретических» вопросов о поведении Core Data, связанных с тем, что происходит с отношением ко многим, и когда следует полагаться на прохождение отношения от родительского объекта и когда должен быть создан новый запрос на выборку. Все они очень связаны.

Предпосылки

Предположим, что родительский объект RPBook имеет отношение ко многим с RPChapter . В книге много глав. Обратное также установлено в базовой модели данных. Используется базовая форма упорядоченных вручную отношений, поэтому сущность RPChapter имеет свойство chapterIndex . Я не использую здесь новые упорядоченные отношения iOS5 (это тоже не имеет отношения к этим вопросам).

Чтобы перейти к главам книги, можно использовать аксессор отношения chapters :

RPBook *myBook; // Assume this is already set to an existing RPBook
NSSet *myChapters = myBook.chapters

Использование / настройка

В приложении для iPhone мы начинаем с табличного представления, показывающего список экземпляров RPBook .Соответствующие главы не будут предварительно загружаться как часть спецификации выборки для контроллера выбранных результатов, поддерживающего табличное представление, поскольку эти главы еще не нужны.

Теперь я выбираю один из тех экземпляров RPBook , меня перенаправляют на новую страницу, и у меня есть ссылка на этот экземпляр RPBook в моем контроллере представления, который НЕ имеет своего глав предварительно загружены.

Вопрос 1: Вызов filterSetUsingPredicate: на chapters сразу же

Если я хочу выполнить фильтрацию через отношение chapters с использованием filterSetUsingPredicate: напрямую, будет ли это работать надежно, учитывая, что я не выполнял предварительную выборку всех связанных RPChapter экземпляров текущей RPBook , на которую я смотрю? Другими словами, filterSetUsingPredicate: вызывает сбой за кулисами всех объектов в этом отношении, чтобы сделать свое дело, или он будет давать мне вводящие в заблуждение результаты только на основе того, какая из глав уже оказалась в память (если есть)?

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

[[self.chapters allObjects] filteredArrayUsingPredicate:predicate]

вместо просто:

[self.chapters filteredSetUsingPredicate:predicate]

Вопрос 2: Пакетное извлечение всех глав книги

В случае, если у меня есть экземпляр RPBook , но нет предварительно загруженного RPChapter связанных с ним случаев, как мне заставить все главы книги быть извлечены одним выстрелом, используя отношение chapters ? Делает ли [myBook.chapters allObjects] это или я все еще могу получать сообщения об ошибках по этому вызову?

Я хочу, чтобы Core Data выполнял все сбои в пакете вместо отключения сбоев для нечетного RPChapter , запрошенного, повлияет ли это на поведение использования filterSetUsingPredicate: в глав , как указано в вопросе 1 выше.

Должен ли я для этого прибегать к явному запросу на выборку? Должен ли я повторно получить RPBook , который у меня уже есть, но на этот раз запрос в запросе на выборку, чтобы все связанные главы также были извлечены с помощью setRelationshipKeyPathsForPrefetching: ?

Этот последний вариант просто кажется расточительно для меня, b / c У меня уже есть отношение области видимости, концептуально представляющее подмножество всех RPChapter экземпляров, которые меня интересуют. Насколько это возможно, я хотел бы просто пройтись по граф объекта.

Вопрос 3: NSFetchedResultsController экземпляров RPChapter в одном потоке

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

Является ли экземпляр RPChapter из FRC тем же объектом в памяти, что и экземпляр экземпляра RPChapter , который я извлекаю из myBook.главы , которые имеют один и тот же ObjectID ? Другими словами, выполняет ли среда выполнения когда-либо запросы управляемых объектов для одного и того же ObjectID из одного и того же MOC в одном потоке, используя разные физические объекты в памяти?

Вопрос 4: Шаблон проектирования установки NSFetchedResultsController внутри управляемого объекта для обслуживания запросов для отношения

Я пытаюсь решить, могу ли я обслуживать запросы о связи, содержимое которой часто меняются (главы в книге в моем примере) с помощью встроенного отношения chapters , предоставленного в моем настраиваемом подклассе управляемых объектов RPChapter , или, если это когда-либо разрешается с точки зрения дизайна / архитектуры с точки зрения установки экземпляров FRC из RPChapter в класс управляемых объектов RPBook для эффективного обслуживания запросов по главам этой книги.

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

Является ли это излишним или справедливым использованием FRC для различных запросов RPBook о его главах? Почему-то мне кажется, что я упускаю возможность просто пройтись по графу объектов.Я хотел бы иметь возможность доверять , что отношение chapters всегда актуально, когда я загружаю свой экземпляр RPBook .