![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Увы, по долгу службы приходится иногда программировать на языке, который если не мой ровесник, то почти (он - 1974 года рождения). И то, что его всячески облагородили в некоей Корпорации Добра, не делает SQL языком программирования. Это какой-то монстр, годный только для Job security на старости лет.
Приведу сегодняшний пример. На Оракловском SQL написана функция, которая должна вернуть простой битовый ответ да/нет на вопрос о членстве пользователя в некой группе. Данные собираются из двух таблиц и результат суммируется через COUNT(*). Всё было бы кошерно, если бы не одно "но": у некоторых пользователей функция упорно возвращает нолик, хотя запустив саму query получаем туеву хучу результатов (многие тыщи). Начали копать, ковырять и мучать эту функцию. Запустили дебаггер (слава яйцам, Корпорация Добра приделала к функциям такую возможность). И что же всплыло? После выполнения запроса функция вылетает по EXCEPTION! Ну какое может быть событие, вызывающее падение тупого запроса (который спокойно работает вне функции)? Копаем дальше - результат запроса попадает в целочисленную переменную... И тут Штирлица осенило: переменная была описана как NUMBER(5), поэтому результат туда иногда не помещался! Проверили - действительно страдающие от дискриминации пользователи получали 6-значное значение. Исправили на NUMBER(10) - нехай тот хомяк подавится - и всё заработало. Да, криворукость автора функции тут тоже присутствует, но бросать EXCEPTION без объяснения причин - свинство.
PS Коллега теперь считает меня колдуном - найти такой баг буквально анализируя сорсы...
Приведу сегодняшний пример. На Оракловском SQL написана функция, которая должна вернуть простой битовый ответ да/нет на вопрос о членстве пользователя в некой группе. Данные собираются из двух таблиц и результат суммируется через COUNT(*). Всё было бы кошерно, если бы не одно "но": у некоторых пользователей функция упорно возвращает нолик, хотя запустив саму query получаем туеву хучу результатов (многие тыщи). Начали копать, ковырять и мучать эту функцию. Запустили дебаггер (слава яйцам, Корпорация Добра приделала к функциям такую возможность). И что же всплыло? После выполнения запроса функция вылетает по EXCEPTION! Ну какое может быть событие, вызывающее падение тупого запроса (который спокойно работает вне функции)? Копаем дальше - результат запроса попадает в целочисленную переменную... И тут Штирлица осенило: переменная была описана как NUMBER(5), поэтому результат туда иногда не помещался! Проверили - действительно страдающие от дискриминации пользователи получали 6-значное значение. Исправили на NUMBER(10) - нехай тот хомяк подавится - и всё заработало. Да, криворукость автора функции тут тоже присутствует, но бросать EXCEPTION без объяснения причин - свинство.
PS Коллега теперь считает меня колдуном - найти такой баг буквально анализируя сорсы...
Tags:
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
(no subject)
Date: 2020-05-05 02:30 pm (UTC)Система категоризации Живого Журнала посчитала, что вашу запись можно отнести к категориям: IT (https://www.livejournal.com/category/it?utm_source=frank_comment), Еда (https://www.livejournal.com/category/eda?utm_source=frank_comment), Лытдыбр (https://www.livejournal.com/category/lytdybr?utm_source=frank_comment).
Если вы считаете, что система ошиблась — напишите об этом в ответе на этот комментарий. Ваша обратная связь поможет сделать систему точнее.
Фрэнк,
команда ЖЖ.
(no subject)
Date: 2020-05-05 03:10 pm (UTC)(no subject)
Date: 2020-05-05 03:51 pm (UTC)(no subject)
Date: 2020-05-05 05:58 pm (UTC)(no subject)
Date: 2020-05-05 06:04 pm (UTC)