среда, 30 октября 2019 г.

ТО о SD 5.1.1.212

Отчёт о тестировании SQLDetective 5.1.1 (build 212), выпущенном 25 октября 2019 года. Проверка осуществлялась по Release Notes, которые не слишком велики, а значит этот билд был выпущен для исправления важного бага, обнаруженного пользователем. После просмотра всего отчёта, надеюсь, вы легко ответите на вопрос "какого бага билд?".

IMPROVEMENTS 1 из 1 возможного
Online Support Desk
⦁ The process of the update downloading is now indicated on the Windows taskbar.
Процесс скачивания апдейта теперь отображается на системном таскбаре.
Такое интерфейсное новшество стоит проверять на всех доступных операционных сестемах (они перечислены в файле Readme.htm или на сайте продукта в блоке System requirements, на сегодняшний день это "Microsoft Windows 7 and above") и их вариациях (стандартная или пользовательская тема расцветки и контрастности, масштабирование). Для теста не обязательно ждать появления следующего билда, а достаточно выбрать ручной режим обновления. Для этого в окне OSD Updater включите опцию "Allow available items to be selected manually". Новшество можно увидеть не только при наличии интернета и скачивании апдейта с сайта, но и при апдейте из файловой системы. Как тестировать, выбирайте сами: либо машину с установленным SD подключить к интернету (не стоит забывать, что в этом случае ваши данные будут переданы на сайт поставщика безусловно и без дополнительных предупреждений), либо скачайте zip-файл с апдейтом (не инсталлятор) и тестируйте много раз на разных системах без тревоги за то, что данные о вашей машине куда-то утекут. Во время копирования апдейта на кнопке приложения, что отображается на таскбаре операционки, заметно течение данных. Имплементация получает балл, хоть и проверен только один случай.

BUGS FIXED  0+0=0 из 5 возможных, -1.5-0.2=-1.7 за баги
Core  0+0-1+1=0 из 4 возможных, -1-0.5=-1.5 за баги
⦁ The error “ORA-00933: SQL command not properly ended” is no longer raised on a script execution if a DDL statement contains an empty string.
Теперь не случается ошибка о неожиданном окончании sql-команды при исполнении скрипта с пустыми стоками в выражениях.
Поскольку баг в группе Core, то проверять исполнение sql-команды придётся не только в SQL Editor, но и через диалог запуска подпрограмм, что доступен из Stored Program Editor. К сожалению, формулировка фикса никак не поясняет какие скрипты невозможно было исполнить, поскольку термин empty string имеет двоякий смысл: толи это просто пустые строки в тексте скрипта, толи это пустые литеральные команды (параметр для выражения EXECUTE IMMEDIATE), толи это пустые значения символьных переменных или ещё что подобное. Ошибка базы ORA-00933  чаще случается для команд, у которых потерялся конец, поэтому возмём простейший случай и вставим пустую строку между служебными словами SELECT и FROM, из череды которых сформируем небольшой скрипт (3-4 выражения, разделённые слешем или точкой с запятой). Например,
select 1

from dual

;
select 2

from dual

/
select 3

from dual
;


Если проверять диалог выполнения подпрограммы из Stored Program Editor, то в предыдущем билде описанная ошибка не проявляется. Если проверять SQL Editor, то выполнять скрипт необходимо не только по четырём доступным кнопкам на тулбаре редактора (весь скрипт, скрипт от курсора, одно выражение под курсором, одну команду под курсором), но и через запуск файла (через команду @). Мне не удалось получить ошибку ORA-00933  в предыдущем билде, поэтому этот пункт RNs считаю припиской и балла не даю. К тому же выяснилось, что так и не исправлен баг с подвисанием окна процесса в SQL Editor (выполните предложенный скрипт в редакторе через Ctrl+Enter, окно процесса не закроется само после окончания выполнения, а при попытке закрыть его и редактор вручную вам будет предложено отправить Eureka-лог ошибки приложения). Поэтому снимаю балл.
⦁ The error “FROM clause not found in SQL” no longer occurs on trying to execute a statement with the apostrophe in a q-notation.
Ошибка необнаружения служебного слова в выражении теперь не случается при выполнении выражения с апострофом в q-нотации.
Стоит вспомнить, что альтернативные кавычки для символьных переменных бажили и в позапрошлом билде. Для теста придётся составить символьное выражение с апострофом внутри (кстати, апостроф и одинарная кавычка - это разные символы) и вложить его в dml-команду с последующим служебным словом FROM (это может быть как и простая команда SELECT, так и вложенные INSERT, DELETE, UPDATE, MERGE), например, select q'[`]' from dual. Поскольку тех.писательница ошиблась и включила пункт RNs не в блок SQL Editor, то верну вас на тропу истины и ограничу тестируемые модули одним редактором, в котором одном можно было бы воспроизвести баг. К сожалению, предыдущий билд не дал описанную ошибку, поэтому и этот пункт причисляю к припискам. 
⦁ Fixed the highlighting of a literal if the opening bracket of a q-notation is followed by a break.
Исправлена подсветка символов, если открываемая кавычка q-нотации следует за переводом строки.
Подсветка текста осуществляется в окнах для просмотра или редактирования кода. Значит этот пункт RNs затерялся в группе Core. За это минус в карму тех.писательницы. У тех, кто фиксил это, должны быть красными уши, потому что вместо улучшения подсветки сделано её ухудшение. В некоторых случаях остаток команды подсвечивается как продолжение символьного выражения в альтернативных кавычках.
Было хорошо, а стало хуже
Такое исправление функционала даёт мне основание отнять балл, а не присудить.
⦁ A single-line comment is now highlighted correctly when it goes after a number.
Однострочный комментарий теперь подсвечивается правильно, если он следует после количества (номера, цифр).
Опять же странное расположение пункта RNs в группе Core, потому что подсветка текста применима в окнах для просмотра и редактирования кода (Code Editor, Text Viewer, SQL Editor, Stored Program Editor, ..). Вторая проблема с пониманием исправления тоже создалась от безалаберности тех.писательницы в выборе терминов. Что имелось ввиду под словами after a number? Толи предыдущая строка кода оканчивается цифрой, толи имелись ввиду номера строк на левом поле, а может и что иное. Для теста в редакторе кода наберём простенький текст:
select 5
--test
 from dual

и поиграем с местом однострочного комментария:
select 5--test
 from dual

Действительно, подсветка закоментированного остатка строки, следующего за цифрой без пробела между ними, не соответствовала ожиданиям в прошлом билде.
Символы после двух минусов в строке считаются комментариями для SQL Oracle
Поэтому даю балл и даже, по доброте душевной, прощаю использование запрещённого слова correctly.

Но поскольку в каждом пункте тех.писательница запутывала юзера, то за все эти промахи сниму полбалла.
Code Insight 0 из 1 возможного, -0.2 за проблемы
⦁ Ctrl+click now works correctly in INSERT and UPDATE statements.
Функциональный клик теперь работает корректно в выражениях INSERT и UPDATE.
Стоит пояснить, что в SD функциональный клик мышью по имени объекта или переменной позиционирует курсор на месте объявления переменной или подпрограммы (если редактор имеет Code Explorer, например "Trigger Wizard / Body" или "Stored Program Editor") и открывает мастер объекта или позиционирует на нём в Object Navigator. Недавно функциональный клик исправляли для нестандартных имён объектов, а теперь для каких-то составляющих или самих команд. Странно, что в список команд не попали остальные dml-выражения (например, MERGE). Поэтому для теста генерим простейшие все dml-выражения, хотя бы через контекстное меню Object Navigator для любой имеющейся у вас таблицы (или вьювера). Из SQL Editor, в который встроили Code Explorer, функционльный клик открывает без изменений мастер таблицы/вьювера для имени схемы и объекта, но ничего не находит для имён столбцов. То есть, никаких фактических изменений, а тем более корректных, найти мне не удалось. Аналогично без изменений остался и Stored Program Editor для перечисленных команд с объявленными и использованными переменными. Поэтому этот пункт однозначно считаю припиской и не даю ни балла. А использованный термин correctly без отсылки к стандартам и отсутствие конкретики при перечислении команд отнимает -0.2 балла.

Итого билд получает 1+0=1 балл из  1+5=6 возможных, то есть исполнен на 1/6=16%. А за баги теряет ещё -1.7 баллов. Предыдущий билд #210 был опубликован неделю назад, то есть этим фикс-билдом команда пыталась загладить свою вину перед пользователями. А как вы считаете, можно ли такими анти-фиксами получить положительную оценку юзеров?



Комментариев нет:

Отправить комментарий