Недавно я работал с NSPredicate — API, который существует с момента выхода Mac OS X Tiger в 2005 году — и то, что выглядело довольно простым, не работало так, как я ожидал.
Я внедрял поддержку Apple Shortcuts в своем приложении для чтения, чтобы пользователи могли автоматизировать процессы взаимодействия. Я заметил, что при использовании EntityPropertyQuery, некоторые, основанные на свойствах, запросы статей не возвращали ожидаемое их количество. У меня было четырнадцать статей, сохраненных на симуляторе iPad. Четыре из них были написаны мной. Однако, когда я искал статьи, где автором был не «Дуглас Хилл», то вместо ожидаемых десяти, в результате получал лишь две.
Было ясно, что статьи не были включены в поиск, если не был указан автор статьи. Другими словами, когда свойство author было равно nil. (Я буду комбинировать термины nil и null, т.к. они представляют одну и ту же концепцию с разными именами в разных программных стеках.)
Отслеживание проблемы
Во-первых, давайте рассмотрим самый простой тест:
Предполагается, что condition в этом случае будет истинным. Если бы мы использовали ==, то результат явно был бы ложным. Однако здесь используется != поэтому мы ожидаем обратного. Хорошие новости: именно так это и работает!
Во-вторых, я запустил быстрый тест в playground, используя NSPredicate в простой ситуации:
Этот тест показал, что при фильтрации объектов, автором которых не был «Дуглас Хилл», включались объекты, где автор был nil. Именно такое поведение я и ожидал.
В этом месте у меня было весьма серьезное подозрение, что это связано с хранилищем SQLite, которое использует мой стек Core Data. Я уверен, что ветераны SQL уже знают ответ.
В-третьих, я провел определенную отладку своего хранилища Core Data без использования Shortcuts и увидел то же самое, что и с Shortcuts: фильтрация по атрибуту(*свойству), не равному какому-либо значению, не будет включать объекты, для которых этот атрибут равен nil.
Я включил -com.apple.CoreData.SQLDebug 3, и это показало непосредственность(*незамысловатость, простоту) генерируемых команд SQL. Данный предикат: author != "Douglas Hill" добавит к команде SQL SELECT это:
WHERE t0.ZAUTHOR<> ?
Где значением ? является:
SQLite bind[0] = "Douglas Hill”
Я никогда не работал с SQL напрямую, только как с элементом реализации (и производительности) Core Data. На данный момент моя гипотеза заключалась в том, что подобная обработка null - именно то, как работает SQL.
К сожалению, SQL не похож на свободный(*независимый) и открытый стандарт, в котором вы легко сможете прочитать указание/спецификацию, чтобы проверить данную деталь. Я провел небольшое исследование в Интернете, и вторичные источники подтвердили мою гипотезу. NULL не считается равным или неравным чему-либо в SQL, или, другими словами, сравнения с null не являются ни истинными, ни ложными.
Этот комментарий jsumrall к вопросу о переполнении стека хорошо подводит итог:
Следует также отметить, что, поскольку != сравнивает только значения, выполнение чего-то вроде WHERE MyColumn != 'somevalue' не вернет NULL.
Чего ожидает пользователь?
С точки зрения программиста, я бы не сказал, что любой из способов обработки null однозначно лучше. Однако от NSPredicate я бы ожидал последовательности (*стабильности). Меня удивило то, что Core Data не сглаживает подобное поведение SQL, чтобы соответствовать тому, как сравнения обычно работают в программных стеках Apple.
С точки зрения пользователя, я думаю, ситуация иная. Пользователи не будут так остро осознавать концепцию null. Есть большая вероятность, что они считают null и пустую строку одним и тем же. Поскольку пользователям мои запросы будут доступны через Shortcuts, я думаю, более ожидаемо, что фильтрация элементов со свойством, не равным какому-либо значению, должна включать элементы, для которых это свойство равно null.
Реализация лучшего поведения
Эту кривизну легко сгладить самостоятельно. Во время настройки предиката для хранилища Core Data SQLite, с условием не быть равным какому-либо значению. Не устанавливайте предикат вот так:
Вместо этого мы также проверяем равенство с nil/null, задавая предикат следующим образом:
На практике это выглядит как удобное расширение для NotEqualToComparator из фреймворка Apple App Intents (Shortcuts API):
Резюме
- В Swift результат nil != nonNilValue является истинным.
- Как правило, NSPredicate, созданный как NSPredicate (формат: "%K != %@", stringKey, nonNilValue), будет соответствовать объектам, у которых свойство, соответствующее stringKey, равно nil.
- При выборке из хранилища Core Data SQLite предикат, созданный, как указано выше, не будет соответствовать объектам, в которых свойство, соответствующее stringKey, равно nil. Это происходит потому, что Core Data напрямую сопоставляет команду с SQL, а SQL указывает, что нет значения, которое равно или неравно null.
- Это можно обойти, создав предикат как NSPredicate(format: "%K != %@ OR %K == NIL", stringKey, nonNilValue, stringKey).
- Урок: Проверяйте все.
Вступай в открытый чат для iOS-разработчиков: t.me/swiftbook_chat