Core Data/NSTextView прерывается только после сохранения

У нас есть NSTextView и некоторые данные о его содержимом, сохраненные в контексте управляемого объекта основных данных. Все отлично работает, пока контекст управляемого объекта остается в памяти. Однако, когда мы сохраняем его, мы получаем очень странное поведение запроса на выборку.

Например, мы запускаем запрос на выборку, который запрашивает все элементы с textLocation меньше или равным 15. Первый объект в массиве, который мы получаем, имеет textLocation 16.

Я знаю, что не могу получить здесь однозначного ответа, так как код довольно сложный. Но кто-нибудь знает, чем пахнет эта проблема?

Я думаю, что мы каким-то образом не синхронизируем правильный MOC с NSTextView после сохранения? Что может изменить это, что сломает это?

Спасибо.


cocoa core-data nstextview nsmanagedobjectcontext core-text
person DexterW    schedule 05.05.2011    source источник

Ответы (2)


arrow_upward
0
arrow_downward

Например, мы запускаем запрос на выборку, который запрашивает все элементы с textLocation меньше или равным 15. Первый объект в массиве, который мы получаем, имеет textLocation 16.

На самом деле, единственный способ получить это (в обратном порядке вероятности):

  1. Испортите определение атрибута так, что вы думаете, что сохраняете один тип числовой информации, но на самом деле сохраняете другой.
  2. Вы исказили предикат так, что он фактически ищет значения 16 или больше. (Вы можете протестировать предикаты на массиве словарей, чьи ключи имеют те же имена, что и ваши объекты Core Data.)
  3. Это ошибка преобразования между числом и строкой для отображения в пользовательском интерфейсе или ведения журнала.

Я бы начал с (3), потому что это кажется более распространенным, и пока вы не подтвердите, что у вас нет проблемы с дисплеем, вы не сможете диагностировать другие проблемы.

person TechZen    schedule 05.05.2011

arrow_upward
0
arrow_downward

Наконец мне удалось понять, что происходит. Я устанавливал textLocation с помощью setPrimitiveValue... только потому, что не хотел, чтобы уведомления срабатывали. Оказывается, это действительно плохая идея, потому что Core Data не знал, что значение изменилось. Он по-прежнему считал, что значение равно 15 вместо 16.

Пусть это будет уроком: никогда не обходите KVO, если вы не находитесь ВНУТРИ управляемого объекта и не знаете, что делаете!

person DexterW    schedule 06.05.2011