С прошлого поста про 1.7.2 вышли четыре версии. Главное направление работы про то, чем работа с Qlik через модель отличается от работы с тем что умеют llm - "работа с бд".
Проблема, вокруг которой всё крутилось
Qlik почти никогда не отвечает ошибкой на кривой запрос.
Он отвечает числом.
- Сгруппировали по полю с опечаткой - Qlik посчитает имя за выражение, вернёт одну строку с общим итогом, и это выглядит как настоящий ответ.
- Отфильтровали по значению, которого в данных нет, получим аккуратную таблицу нулей.
- Написали фильтр по дате не в той форме - получим итог за весь период.
Ни в одном из случаев в ответе нет ничего, за что можно зацепиться. Для человека это неудобно, для модели - фатально: она процитирует число как факт.
Что сделано в 2.0
Вопрос описывается словами, а выражения пишет сервер.
{
"group_by": ["region_name"],
"metrics": [{"field": "amount", "agg": "sum"}],
"filters": [{"field": "order_date", "period": "2024"}]
}
Ни строчки синтаксиса Qlik. Модель не ошибается в том, чего не пишет.
Форму фильтра по датам сервер подбирает замером. Оказалось, что угадать её нельзя в принципе: сравнение внутри set-анализа идёт с тем, как значение выглядит на экране, а не с тем, как хранится. На поле, которое показывается как
01.01.2024, фильтр по числу 45292 не работает и молчит об этом. На соседнем поле, которое показывается голым числом, работает только он - и в шестьдесят раз быстрее.
Поэтому сервер сначала считает эталон, потом пробует дешёвый вариант и берёт его, только если ответ совпал.
Ответ можно проверить по нему самому. Расчёт за период возвращает крайние даты того, что реально попало в счёт. Вышли за границы запроса - значит Qlik условие отбросил, и это видно сразу.
Проверки перед расчётом делает сам Qlik. Раскрытие переменных, синтаксис, имена полей, поля внутри модификатора - всё спрашивается у движка. Пакет проверок стоит 4 миллисекунды против секунд на расчеты гиперкуба. Собственный разбор формул регулярками убран целиком.
Несколько вопросов идут одним обращением. Список независимых запросов выполняется за те же пять обращений к Qlik, что и один. Три разных вопроса - за 0,16 секунды.
Даты пишутся одинаково везде. Раньше расчёт возвращал
45292, а образцы значений того же поля - 01.01.2024.Что было до этого
версия 1.9 научился отказывать вместо того, чтобы отвечать неверно. Несуществующее поле в группировке - отказ с подсказкой похожего имени, а не строка с общим итогом. В каждом ответе появились предупреждения: мера, которая везде ноль, SQL, написанный вместо выражения Qlik, пустой результат. Объекты листа стали отдавать поля и выражения, которыми они пользуются, - включая мастер-элементы и поля внутри фильтров.
версия 1.8 была про то, чтобы данные не терялись молча. Постраничная выборка переехала на сторону Qlik: раньше приложения за пределом лимита записей просто не существовали для сервера, а общее число врало.
Поиск по значениям поля тоже ушёл в движок - на поле с 200 тысячами значений локальный просмотр не мог найти совпадение в принципе.
Вызовы к движку сериализованы: параллельные обращения по одному сокету выбрасывали ответы друг друга.
Удалено 55 избыточных методов, это около 1180 строк, включая один, падавший на каждом вызове.
Там же схема в адресе стала определять транспорт целиком, а проверка сертификата выключилась по умолчанию: Qlik Sense отдаёт самоподписанный сертификат, и с включённой проверкой корректная установка не работала.
Количество настроек уменьшилось с 24 до 15 - но по факту, там теперь везде дефолтных хватает, не нужно отдельно ничего тюнинговать
Исходники и описание: https://github.com/bintocher/qlik-sense-mcp
