NSFetchedResultsController ~ кеш, вызывающий проблемы? - PullRequest
0 голосов
/ 30 августа 2010

Хорошо, здесь идет моя установка:

Модель объекта:

* Category object is at the root  
* Product is linked to a Category (many-to-1)
* ShoppingItem is linked to a Product (many-to-1)

Настройка приложения:

Мое приложение имеет TabBarController в корне и tableviewcontroller в корне каждой вкладки.

  • Первый контроллер tableview показывает все ShoppingItems
    • Он использует NSFetchedResultsController для извлечения данных
    • Сортировочный дескриптор для этого контроллера установлен как «Product.Category.Name»
    • Параметр sectionNameKeyPath установлен как «Product.Category.Name»
    • Предикат не установлен
    • Для этого NSFRC установлено имя кэша
    • Это помогает мне сгруппировать товары по категориям продуктов по разделам.
  • Второй tableviewcontroller показывает все продукты
    • Он также использует NSFRC для извлечения данных
    • Sortdescriptor - "Category.Name"
    • SectionNameKeyPath - «Category.Name»
    • Набор предикатов "Актив == 1" - для загрузки только активных продуктов
    • Для этого NSFRC также установлено имя кэша
    • Это помогает мне сгруппировать продукты по категориям в разделы.

Сценарий:

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

Оба контроллера таблицы просмотра настроены одинаково, чтобы NSFRCDelegate уведомлял их об изменениях в информации о секциях и строках.

Есть какие-нибудь подсказки, что здесь происходит? Это поведение правильно?

P.S. : Я работаю @ и не могу публиковать фрагменты кода. Можете пойти домой и сделать это, если это поможет.

Ответы [ 3 ]

0 голосов
/ 01 сентября 2010

Странная проблема, если не сказать больше. Может ли быть так, что NSFetchedResultsController не получает уведомлений об изменениях в разделе при использовании ключевого пути имени раздела из более чем двух уровней?

Вы можете попробовать следующий обходной путь, чтобы проверить этот пункт:

Добавьте свойство только для чтения с именем "categoryName" в свой класс ShoppingItem со следующей реализацией:

- (NSString *)categoryName {
    return self.Product.Category.Name;
}

Затем добавьте следующий метод в вашу реализацию ShoppingItem:

+ (NSSet *)keyPathsForValuesAffectingCategoryName {
   return [NSSet setWithObjects:@"Product.Category.Name", nil];
}

Это гарантирует, что каждый раз, когда имя категории изменяется, система KVO также будет инициировать уведомление об изменении для categoryName, таким образом, мы надеемся, что NSFRC получит уведомление об изменении. Конечно, используйте categoryName в качестве sectionNameKeyPath вашего NSFRC.

Дайте мне знать, если это работает.

0 голосов
/ 28 июня 2012

попробуйте использовать разные имена кэша для другой конфигурации (т. Е. Разные сортировки или предикаты) - он должен иметь возможность возвращать правильные данные.Это сработало у меня.

0 голосов
/ 30 августа 2010

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

Я думаю, что более вероятно, что у вас два разных контекста управляемого объекта. У вас есть один контекст для таблицы Product и другой общий для таблицы Change-view и ShoppingItems.

Если таблица ShoppingItems и ракурс изменений имеют общий контекст, то любые изменения, сделанные в ракурсе изменений, будут автоматически отображаться в таблице ShoppingItems, но эти изменения не будут отображаться в таблице покупок, если вы не объедините изменения контекста.

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

...