Отчёт о тестировании SQLDetective 5.0.1.145(6)(8), опубликованном 18 апреля 2019 года. Номер билда "145/146/148" варьируется в разных источниках, но текст Release Notes, по которому выполнялись проверки, един во всех местах. Такие казусы случаются из-за длительных публикаций, когда первый выпуск не зашёл и продукт пришлось пересобирать из-за какого-то хот-фикса, но номер билда, меняемый разработчиками до сих пор вручную в некоторых отчётах на сайте и в продукте, может затеряться и путать юзера.
IMPROVEMENTS 0.9-0.3+2.1+0+0.7+0.8+0.3=4.5 из 2+3+3+1+1+1+1=12 возможных, -0.5 за проблемы
Core 0.2+0.7=0.9 из 2 возможных
* SQLDetective can now connect to databases in MOUNT mode.
Теперь можно подконнектиться к базе в режиме построения.
Немного теории от админа базы Oracle. Старт базы делится на 4 этапа: shutdown, nomount, mount, open. В режиме построения перед конечным открытием можно сменить установки базы или переназначить файлы с глобальными параметрами, которые невозможно менять в рабочем (open) состоянии базы. Переключение стадий в режимы MOUNT и OPEN производится командой ALTER DATABASE обычно в SQL*Plus. К сожалению, ни в хелпе, ни в RNs не уточняется, какой способ подключения к базе разрешён теперь в SD на стадии построения базы: через интерфейс окна DB Connect или только локально в SQL Editor (подключенная сессия не работает во всех иных окнах приложения, кроме редактора). Исследовательское тестирование показало, что в предыдущем билде системный юзер мог подключаться к базе в режиме mount только локально в SQL Editor без возможности полноценно открыть базу, а текущий билд позволяет системным пользователем подключиться к базе через общий интерфейс, частично работать с базой в окнах SD, выполнить в редакторе команду по полному открытию базы "ALTER DATABASE OPEN". Поскольку в хелпе не указаны выясненные мной особенности новшества, то оно получает лишь 0.7 балла.
* Added the ability to connect to a database using Oracle Wallet.
Добавлена возможность коннекта к базе через Oracle Wallet.
Чтобы понять все преимущества Oracle Wallet вам придётся прошерстить документацию базы, поскольку хелп SD ни чем не ограничил поддержку. Так что, кроме самого процесса коннекта к базе вы вполне можете требовать полной реализации всех полезностей Oracle Wallet в рамках SD интерфейса. В частности, поскольку Oracle Wallet можно считать некоей разновидностью tns-типа подключения с различным местом хранения его установок (реестр, файловая система), то интерфейс окна подключения к базе должен был претерпеть значительные изменения. Да и в хелпе нет ни слова о том, как в рамках имеющихся окон и их элементов стоит применять Oracle Wallet. Поэтому однозначно можно считать этот пункт RNs фикцией. Аналогичным образом ConquestSS обычно заявляет о поддержке новой версии базы, а на самом деле вставляет в код продукта лишь один костыль, оправдывающий мощное заявление на каких-нибуль один-два процента. Максимально такая мнимая фича заслуживает 0.2 балла.
Database Monitor -0.5-0.5+0.7=-0.3 из 3 возможных
* Added the ability to perform SQL tracing using the DBMS_MONITOR package:
** The SQL Trace options are now opened in a separate window on enabling SQL Trace.
** Removed the SQL Trace options from Preferences.
Добавлена возможность запускать трассировку через пакет DBMS_MONITOR:
-- Опции трассировки открываются теперь в отдельном окне при включении трассировщика;
-- Убраны опции трассировки из настроек приложения.
Хоть это новшество и оформлено как единый пункт RNs, но мы вполне можем тестировать его как три самостоятельных пункта. Начнём с простого, с конца, и попытаемся отыскать то, что удалено.
Сравнив настройки монитора базы обнаружим, что тех.писательница ошиблась в наименовании модуля. Трассировка запускается не в рамках DB Monitor, а в другой утилите админа базы - Session Navigator. К тому же в хелпе "Session Navigator – Enable/Disable SQL Tracing" имеется таже опечатка с именем модуля. Поэтому у каждого из трёх пунктов снизим балл. Ещё часть балла снизим пункту удаления опции за счёт нелогичного его места в RNs. Дальнейшие тесты нового функционала и интерфейса, к сожалению, выполнить невозможно из-за давнишнего бага при попытке загрузить данные базы в окно. На некоем мультибайтовом символе процесс прекращается и окно Session Navigator остаётся пустым и бесполезным. В окне без данных нет возможности запустить трейсер и хотя бы поглазеть на новый внешний вид опций. Также сомневаюсь, что юзеру так уж важно при каждом запуске трейсера менять или проверять настройки, то есть вынос их в отдельное окно ничем не оправдан. Поэтому из-за блокера баллы теряются, а не добавляются.
SQL Editor 0.8+0.8+0.5=2.1 из 3 возможных
* Removed unnecessary synchronization options of the Data and Editor tabs from Preferences.
Убраны ненужные опции синхронизации выходных данных и исполненного скрипта из настроек.
Странно, что пункт RNs не в блоке Removed и группе Preferences, если опираться на логичные стандарты структуры таких документов. Почему эти установки стали лишними и действительно ли выполнено изменение проверим вместе со следующим пунктом RNs.
* The Data and Editor tabs are now always synchronized by default.
Закладки выходных данных и скрипта теперь всегда синхронизированы по-умолчанию.
Из группы в пять чек-боксов настроек "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Editor and Data tabs synchronization" остался один чек-бокс. Перед началом тестов стоит отметить, что работа этих опций не должна пересекаться с функционалом чекера "SQL Editor / Smart Output". Хоть продукт SD уже приближается к совершеннолетию, но его разработка до сих пор считается стартапом, но со спринтами длиною в пару-тройку лет, а порой и больше. Опции синхронизации закладок появились в версии 4.3 в конце 2009 года. Ещё тогда мне их обилие было в тягость, и одним из предложений было сократить список опций. И вот, спустя 10 лет разработчики одумались, видимо после обилия жалоб юзеров, которые тоже сильно путались в этой массе настроек с длинными именами и перемежающейся логикой. Изменения такого порядка отношу к разряду "отшпили-зашпили" (в старом советском фильме малыш не мог сам управляться с помочами и постоянно обращался к старшим с этой просьбой), когда владельцу продукта не даёт спокойствия мысль о свершении чего-то существенного и потому он подчинённых теребит заявками внедрять и выкручивать то одну, то другую фичу. А мы с вами поглядим, действительно ли такое "отсечение напрочь всего" улучшило работу юзеру. Если судить по описанию фичи в хелпе, то функционал серьёзно уменьшился после удаления опций: пропали возможности переименовывать и закрывать закладки синхронно, открывать для каждого нового запроса свою закладку данных.
На каждую из удалённых опций придётся проделать одинаковые непересекающиеся тесты: включить/выключить только одну опцию в предыдущем билде, перезагрузить приложение в текущем билде, выполнить запросы из нескольких редакторов, покликать по закладкам, переименовывать и закрывать их. Понаблюдаем за логикой и передачей функционала из предыдущего билда в текущий. Полное отключение всех пяти опций в предыдущем билде не отключает единственную в текущем - хороший знак того, что они не наследуются и не пересекаются. Но весьма странным выглядит тот факт, что функционал всех пяти опций теперь скинут в одну оставшуюся, но в хелпе не осталось никаких деталей. В скрытых знаниях оказались возможности по переименованию, закрытию и открытию закладок. Кстати, не запутайтесь и вы, надеясь на применимость опции "Preferences / Dataset Editors / Smart Dataset / Open separate window for each object" в рамках закладки "SQL Editor / Data Output". В остальном чек-лист для проверки объединённой опции получается почти зелёным и оба изменения засчитаны, но из-за неполноценности хелпа и сомнительной полезности отката дам по 0.8 балла, вместо снятия этих пунктов как багов.
В процессе тестирования окно SQL Editor проявило себя не с лучшей стороны при совместном исполнении нескольких select-запросов из одного скрипта и при некоторых выводах единственных выражений скрипта. Закладки с данными с трудом прорисовывались, но поработать ни с одной из них не получалось, так как всё приложение нуждалось в перезагрузке из-за AV-ошибки и подвисающего окна исполнения скрипта.
* The confirmation window now appears on executing all DDL statements, e.g. TRUNCATE, and all missing DML statements, e.g. LOCK TABLE (except for SELECT).
Окно подтверждения теперь появляется при выполнении всех DDL выражений, в том числе TRUNCATE, для всех пропущенных DML выражений, в том числе LOCK TABLE, но исключая SELECT.
Для появления подтверждений на выполнение DML и/или DDL команд в рамках SD и в том числе в окне SQL Editor, необходимо перед подключением сессии (не локальным через выполнение команды connect только в редакторе) в опциях подключения выставить соответствующие параметры "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DML (insert, delete, pl\sql block" и/или "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DDL (create, alter, drop, truncate, etc)". В рамках подготовки статей об оъектах хранения данных и их безопасности меня смутил тот факт, что столь опасная команда TRUNCATE, мгновенно удаляющая все данные из таблицы без возможности отката, не включена в список для предупреждений ПО, предназначенного упрощать работу пользоватулю всеми возможными способами. Спасибо разработчикам, они расширили моё давнишнее предложение командой LOCK TABLE. К сожалению, тех.писательница не обладает достаточными знаниями и по ошибке причислила команду к DML, поскольку согласно документации Oracle и в частности в статье "Description of Static SQL" к DML относятся команды INSERT, UPDATE, DELETE и MERGE, к TCL относятся COMMIT, ROLLBACK, SAVEPOINT и SET TRANSACTION, а команда LOCK TABLE не считается ни DML, ни TCL, а только Static SQL.
Статья "Transaction Management" документации Oracle гласит:
DDL statements include the following:
* CREATE, ALTER and DROP statements for any database object, including tables, views, users, procedures and indexes.
* TRUNCATE
* GRANT and REVOKE
В общих положениях о базе командами языка DDL считаются: "Data Definition Language (DDL) statements manage schema objects in the database. These statements create new, drop old, and establish schema objects. They also control access to schema objects.", а командами языка DML: "Data Manipulation Language (DML) statements can change data in database tables. For example, DML statements insert new rows into a table, update column values in existing rows, delete rows from a table, lock a table in the database, and explain the execution plan for a SQL statement.". Более полную картину мне давно пришлось собрать в единую таблицу для ускорения передачи знаний новичкам. Две команды TCL (COMMIT, ROLLBACK) имеют свою систему подтверждений ("Preferences / General / Session / Auto commit after each statement", "Preferences / General / Session / On Disconnect", "Preferences / General / Session / Confirm commit and rollback") в интерфейсе SD.
Поскольку в описании новшества есть фраза "для всех команд", то чек-лист составлять надо по документации Oracle и проверить наличие и отсутствие предупреждений для полных списков. К тому же, опция про DDL команды переименована так, что можно предположить поддержку абсолютно всех синтаксисов. Если бы тех.писательница ограничилась фразами только о добавленных двух командах, то вам не потребовалось бы столь глубоко изучать разницу языков. По этой же причине сразу могу заключить, что разработчикам стоило переименовать опцию "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DML (insert, delete, pl\sql block" в "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / PL\SQL Block, Static SQL (exclude SELECT and TCL commands)". Очень странным мне давно кажется включение pl\sql блоков в разряд DML. А поскольку блок может состоять из множества DML-команд, то возникает подозрение, что для каждой из них будет срабатывать предупреждение. Ещё одной стороной проверок является жёсткая привязка новшества к модулю, хотя очистить таблицу от данных (или миновать корзину, или восстановить) можно и из главного меню или навигатора объектов. А как вы думаете, будет ли предупреждение на команды внутри анонимного блока, выполненного в рамках Stored Program Editor? Для полноты тестов придётся заполнить таблицу:
Из получившейся таблицы можно оформить множество багов (подсвечено красным) и предложений (подсвечено сиреневым) по усовершенствованию работы приложения. Но отдельно можно однозначно считать багом тот факт, что отвергнутые от исполнения команды диалогом конфирмации в SQL Editor попадают в список SQL History со статусом Done.
По-моему, не отправленные в базу команды должны сохраняться в списке историй SQL Editor с особым статусом, отличным от Failed и Done, но этот статус не должен подпадать под инвалидные, чтобы юзеру было удобно от наличия команды в динамичных помощниках.
Вполне возможно, что кто-то из вас покрутит у виска и промолвит "горе от ума", но столь обильные тесты мы вынуждены проводить по нескольким причинам:
- продуктом SD пользуются более грамотные знатоки Oracle, чем я, и скорее всего мой чек-лист окажется мал для них;
- знание предметной области - первоочередная задача как программиста, так и тех.писателя, чтобы исключить ошибки в текстах RNs;
- неточности в описании фикса приводят к недопониманию его пользователем и, как следствие, приводят к разочарованию возможностями продукта.
Сколько дать баллов за новшество? Учитывая текст RNs, переименование опций и показательно-частичную реализацию могу дать лишь 0.5 балла. По доброте душевной не буду снимать баллы за недоделки и наличие термина all.
Object Wizards 0 из 1 возможного, -0.5 за проблемы
* Increased the object name length to 128 characters.
Длина имени объекта увеличена до 128 символов.
Последние версии (12.2 и позже) базы данных Oracle улучшены так, что имена объектам стало можно давать не ограничиваясь тридцатью символами и двумя кавычками, а намного больше. Но создать объект через его мастер в SD у вас не получится, потому что интерфейсы мастеров всех типов до сих пор обрезают ввод 32-мя символами, за что можно снять -0.5 балла.
Code Formatter 0.7 из 1 возможного
* Added a new linefeed “Before the RETURN clause of a function declaration”.
Добавлено новое обрамление кода пустой строкой перед объявлением выражения выхода из функции.
Поскольку опция добавлена в форматтер, то искать её следует на странице "Edit / Format / Formatter Options.. / Code Analyzer Options / Formatter Options / General Layout / Linefeeds". Хелп не рассказывает подробно о каждой настройке форматирования, поэтому и не обновлён из-за добавления новой опции. Наименование опции в интерфейсе SD не уточняет, что речь идёт только об области объявления функции, либо оно обрезано на странице опций. Так что исследование проведём на самостоятельной и пакетной функциях для области объявления и использования выходного выражения. Выражение выхода из функции может быть единственным в её объявлении и множественным в теле. Поэтому предлагаю такой код:
CREATE OR REPLACE FUNCTION sevr_return(prm IN number) RETURN VARCHAR2 AS
BEGIN RETURN 'ok';
EXCEPTION WHEN OTHERS THEN RETURN 'bad';
END;
Дополнительная пустая строка в теле функции перед строкой выхода не добавляется при форматировании. А любое объявление (самостоятельная функция, спецификация или тело пакета) функции разбивается на две строки, выровненные по словам FUNCTION и RETURN. По результатам исследования могу дать лишь 0.7 балла.
Code Review Rules 0.8 из 1 возможного
* The violation of the rule “The alias is missing for a table reference in a multi-source query” is no longer raised if the table name used in the query is shorter than 4 characters.IMPROVEMENTS 0.9-0.3+2.1+0+0.7+0.8+0.3=4.5 из 2+3+3+1+1+1+1=12 возможных, -0.5 за проблемы
Core 0.2+0.7=0.9 из 2 возможных
* SQLDetective can now connect to databases in MOUNT mode.
Теперь можно подконнектиться к базе в режиме построения.
Немного теории от админа базы Oracle. Старт базы делится на 4 этапа: shutdown, nomount, mount, open. В режиме построения перед конечным открытием можно сменить установки базы или переназначить файлы с глобальными параметрами, которые невозможно менять в рабочем (open) состоянии базы. Переключение стадий в режимы MOUNT и OPEN производится командой ALTER DATABASE обычно в SQL*Plus. К сожалению, ни в хелпе, ни в RNs не уточняется, какой способ подключения к базе разрешён теперь в SD на стадии построения базы: через интерфейс окна DB Connect или только локально в SQL Editor (подключенная сессия не работает во всех иных окнах приложения, кроме редактора). Исследовательское тестирование показало, что в предыдущем билде системный юзер мог подключаться к базе в режиме mount только локально в SQL Editor без возможности полноценно открыть базу, а текущий билд позволяет системным пользователем подключиться к базе через общий интерфейс, частично работать с базой в окнах SD, выполнить в редакторе команду по полному открытию базы "ALTER DATABASE OPEN". Поскольку в хелпе не указаны выясненные мной особенности новшества, то оно получает лишь 0.7 балла.
* Added the ability to connect to a database using Oracle Wallet.
Добавлена возможность коннекта к базе через Oracle Wallet.
Чтобы понять все преимущества Oracle Wallet вам придётся прошерстить документацию базы, поскольку хелп SD ни чем не ограничил поддержку. Так что, кроме самого процесса коннекта к базе вы вполне можете требовать полной реализации всех полезностей Oracle Wallet в рамках SD интерфейса. В частности, поскольку Oracle Wallet можно считать некоей разновидностью tns-типа подключения с различным местом хранения его установок (реестр, файловая система), то интерфейс окна подключения к базе должен был претерпеть значительные изменения. Да и в хелпе нет ни слова о том, как в рамках имеющихся окон и их элементов стоит применять Oracle Wallet. Поэтому однозначно можно считать этот пункт RNs фикцией. Аналогичным образом ConquestSS обычно заявляет о поддержке новой версии базы, а на самом деле вставляет в код продукта лишь один костыль, оправдывающий мощное заявление на каких-нибуль один-два процента. Максимально такая мнимая фича заслуживает 0.2 балла.
Database Monitor -0.5-0.5+0.7=-0.3 из 3 возможных
* Added the ability to perform SQL tracing using the DBMS_MONITOR package:
** The SQL Trace options are now opened in a separate window on enabling SQL Trace.
** Removed the SQL Trace options from Preferences.
Добавлена возможность запускать трассировку через пакет DBMS_MONITOR:
-- Опции трассировки открываются теперь в отдельном окне при включении трассировщика;
-- Убраны опции трассировки из настроек приложения.
Хоть это новшество и оформлено как единый пункт RNs, но мы вполне можем тестировать его как три самостоятельных пункта. Начнём с простого, с конца, и попытаемся отыскать то, что удалено.
 |
| Опции были в модуле Session Navigator, а не в DB Monitor |
Сравнив настройки монитора базы обнаружим, что тех.писательница ошиблась в наименовании модуля. Трассировка запускается не в рамках DB Monitor, а в другой утилите админа базы - Session Navigator. К тому же в хелпе "Session Navigator – Enable/Disable SQL Tracing" имеется таже опечатка с именем модуля. Поэтому у каждого из трёх пунктов снизим балл. Ещё часть балла снизим пункту удаления опции за счёт нелогичного его места в RNs. Дальнейшие тесты нового функционала и интерфейса, к сожалению, выполнить невозможно из-за давнишнего бага при попытке загрузить данные базы в окно. На некоем мультибайтовом символе процесс прекращается и окно Session Navigator остаётся пустым и бесполезным. В окне без данных нет возможности запустить трейсер и хотя бы поглазеть на новый внешний вид опций. Также сомневаюсь, что юзеру так уж важно при каждом запуске трейсера менять или проверять настройки, то есть вынос их в отдельное окно ничем не оправдан. Поэтому из-за блокера баллы теряются, а не добавляются.
SQL Editor 0.8+0.8+0.5=2.1 из 3 возможных
* Removed unnecessary synchronization options of the Data and Editor tabs from Preferences.
Убраны ненужные опции синхронизации выходных данных и исполненного скрипта из настроек.
Странно, что пункт RNs не в блоке Removed и группе Preferences, если опираться на логичные стандарты структуры таких документов. Почему эти установки стали лишними и действительно ли выполнено изменение проверим вместе со следующим пунктом RNs.
* The Data and Editor tabs are now always synchronized by default.
Закладки выходных данных и скрипта теперь всегда синхронизированы по-умолчанию.
Из группы в пять чек-боксов настроек "Preferences / Code Editors / SQL Editor / Editor and Tab Handling / Editor and Data tabs synchronization" остался один чек-бокс. Перед началом тестов стоит отметить, что работа этих опций не должна пересекаться с функционалом чекера "SQL Editor / Smart Output". Хоть продукт SD уже приближается к совершеннолетию, но его разработка до сих пор считается стартапом, но со спринтами длиною в пару-тройку лет, а порой и больше. Опции синхронизации закладок появились в версии 4.3 в конце 2009 года. Ещё тогда мне их обилие было в тягость, и одним из предложений было сократить список опций. И вот, спустя 10 лет разработчики одумались, видимо после обилия жалоб юзеров, которые тоже сильно путались в этой массе настроек с длинными именами и перемежающейся логикой. Изменения такого порядка отношу к разряду "отшпили-зашпили" (в старом советском фильме малыш не мог сам управляться с помочами и постоянно обращался к старшим с этой просьбой), когда владельцу продукта не даёт спокойствия мысль о свершении чего-то существенного и потому он подчинённых теребит заявками внедрять и выкручивать то одну, то другую фичу. А мы с вами поглядим, действительно ли такое "отсечение напрочь всего" улучшило работу юзеру. Если судить по описанию фичи в хелпе, то функционал серьёзно уменьшился после удаления опций: пропали возможности переименовывать и закрывать закладки синхронно, открывать для каждого нового запроса свою закладку данных.
 |
| Объединение пяти опций в одну |
 |
| Два одновременных запроса после исполнения подвешивают SD |
* The confirmation window now appears on executing all DDL statements, e.g. TRUNCATE, and all missing DML statements, e.g. LOCK TABLE (except for SELECT).
Окно подтверждения теперь появляется при выполнении всех DDL выражений, в том числе TRUNCATE, для всех пропущенных DML выражений, в том числе LOCK TABLE, но исключая SELECT.
Для появления подтверждений на выполнение DML и/или DDL команд в рамках SD и в том числе в окне SQL Editor, необходимо перед подключением сессии (не локальным через выполнение команды connect только в редакторе) в опциях подключения выставить соответствующие параметры "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DML (insert, delete, pl\sql block" и/или "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DDL (create, alter, drop, truncate, etc)". В рамках подготовки статей об оъектах хранения данных и их безопасности меня смутил тот факт, что столь опасная команда TRUNCATE, мгновенно удаляющая все данные из таблицы без возможности отката, не включена в список для предупреждений ПО, предназначенного упрощать работу пользоватулю всеми возможными способами. Спасибо разработчикам, они расширили моё давнишнее предложение командой LOCK TABLE. К сожалению, тех.писательница не обладает достаточными знаниями и по ошибке причислила команду к DML, поскольку согласно документации Oracle и в частности в статье "Description of Static SQL" к DML относятся команды INSERT, UPDATE, DELETE и MERGE, к TCL относятся COMMIT, ROLLBACK, SAVEPOINT и SET TRANSACTION, а команда LOCK TABLE не считается ни DML, ни TCL, а только Static SQL.
Статья "Transaction Management" документации Oracle гласит:
DDL statements include the following:
* CREATE, ALTER and DROP statements for any database object, including tables, views, users, procedures and indexes.
* TRUNCATE
* GRANT and REVOKE
В общих положениях о базе командами языка DDL считаются: "Data Definition Language (DDL) statements manage schema objects in the database. These statements create new, drop old, and establish schema objects. They also control access to schema objects.", а командами языка DML: "Data Manipulation Language (DML) statements can change data in database tables. For example, DML statements insert new rows into a table, update column values in existing rows, delete rows from a table, lock a table in the database, and explain the execution plan for a SQL statement.". Более полную картину мне давно пришлось собрать в единую таблицу для ускорения передачи знаний новичкам. Две команды TCL (COMMIT, ROLLBACK) имеют свою систему подтверждений ("Preferences / General / Session / Auto commit after each statement", "Preferences / General / Session / On Disconnect", "Preferences / General / Session / Confirm commit and rollback") в интерфейсе SD.
Поскольку в описании новшества есть фраза "для всех команд", то чек-лист составлять надо по документации Oracle и проверить наличие и отсутствие предупреждений для полных списков. К тому же, опция про DDL команды переименована так, что можно предположить поддержку абсолютно всех синтаксисов. Если бы тех.писательница ограничилась фразами только о добавленных двух командах, то вам не потребовалось бы столь глубоко изучать разницу языков. По этой же причине сразу могу заключить, что разработчикам стоило переименовать опцию "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / DML (insert, delete, pl\sql block" в "Oracle Database Connection / Options / Connection Settings / Confirm execution required for the following statements / PL\SQL Block, Static SQL (exclude SELECT and TCL commands)". Очень странным мне давно кажется включение pl\sql блоков в разряд DML. А поскольку блок может состоять из множества DML-команд, то возникает подозрение, что для каждой из них будет срабатывать предупреждение. Ещё одной стороной проверок является жёсткая привязка новшества к модулю, хотя очистить таблицу от данных (или миновать корзину, или восстановить) можно и из главного меню или навигатора объектов. А как вы думаете, будет ли предупреждение на команды внутри анонимного блока, выполненного в рамках Stored Program Editor? Для полноты тестов придётся заполнить таблицу:
| SE | SPE | Wizard, ON, main menu | |
|---|---|---|---|
| DELETE | ok | no | ok |
| EXPLAIN | no | n/a | no |
| INSERT | ok | no | ok |
| LOCK TABLE | ok | no | n/a |
| MERGE | ok | no | no |
| UPDATE | ok | no | ok |
| ALTER | ok | n/a | ok |
| CREATE | ok | n/a | ok |
| DROP | ok | n/a | ok |
| FLASHBACK | ok | n/a | n/a |
| GRANT | no | n/a | no |
| PURGE | no | n/a | no |
| RENAME | ok | n/a | ok |
| REVOKE | ok | n/a | no |
| TRUNCATE | ok | n/a | ok |
| Anonymous Block | ok | n/a | n/a |
| DDL in Anonymous Block | no | n/a | n/a |
| DML in Anonymous Block | no | n/a | n/a |
| ADMINISTER | no | n/a | n/a |
| ANALYZE | ok | n/a | no |
| ASSOCIATE | ok | n/a | n/a |
| AUDIT | ok | n/a | n/a |
| CALL | ok (DML) | n/a | n/a |
| COMMENT | ok | n/a | ok (DDL) |
| DISASSOCIATE | ok | n/a | n/a |
| NOAUDIT | ok | n/a | n/a |
| SET (constraint, role) | no | n/a | no |
По-моему, не отправленные в базу команды должны сохраняться в списке историй SQL Editor с особым статусом, отличным от Failed и Done, но этот статус не должен подпадать под инвалидные, чтобы юзеру было удобно от наличия команды в динамичных помощниках.
Вполне возможно, что кто-то из вас покрутит у виска и промолвит "горе от ума", но столь обильные тесты мы вынуждены проводить по нескольким причинам:
- продуктом SD пользуются более грамотные знатоки Oracle, чем я, и скорее всего мой чек-лист окажется мал для них;
- знание предметной области - первоочередная задача как программиста, так и тех.писателя, чтобы исключить ошибки в текстах RNs;
- неточности в описании фикса приводят к недопониманию его пользователем и, как следствие, приводят к разочарованию возможностями продукта.
Сколько дать баллов за новшество? Учитывая текст RNs, переименование опций и показательно-частичную реализацию могу дать лишь 0.5 балла. По доброте душевной не буду снимать баллы за недоделки и наличие термина all.
Object Wizards 0 из 1 возможного, -0.5 за проблемы
* Increased the object name length to 128 characters.
Длина имени объекта увеличена до 128 символов.
Последние версии (12.2 и позже) базы данных Oracle улучшены так, что имена объектам стало можно давать не ограничиваясь тридцатью символами и двумя кавычками, а намного больше. Но создать объект через его мастер в SD у вас не получится, потому что интерфейсы мастеров всех типов до сих пор обрезают ввод 32-мя символами, за что можно снять -0.5 балла.
Code Formatter 0.7 из 1 возможного
* Added a new linefeed “Before the RETURN clause of a function declaration”.
Добавлено новое обрамление кода пустой строкой перед объявлением выражения выхода из функции.
Поскольку опция добавлена в форматтер, то искать её следует на странице "Edit / Format / Formatter Options.. / Code Analyzer Options / Formatter Options / General Layout / Linefeeds". Хелп не рассказывает подробно о каждой настройке форматирования, поэтому и не обновлён из-за добавления новой опции. Наименование опции в интерфейсе SD не уточняет, что речь идёт только об области объявления функции, либо оно обрезано на странице опций. Так что исследование проведём на самостоятельной и пакетной функциях для области объявления и использования выходного выражения. Выражение выхода из функции может быть единственным в её объявлении и множественным в теле. Поэтому предлагаю такой код:
CREATE OR REPLACE FUNCTION sevr_return(prm IN number) RETURN VARCHAR2 AS
BEGIN RETURN 'ok';
EXCEPTION WHEN OTHERS THEN RETURN 'bad';
END;
Дополнительная пустая строка в теле функции перед строкой выхода не добавляется при форматировании. А любое объявление (самостоятельная функция, спецификация или тело пакета) функции разбивается на две строки, выровненные по словам FUNCTION и RETURN. По результатам исследования могу дать лишь 0.7 балла.
Code Review Rules 0.8 из 1 возможного
Правило о пропущенном алиасе таблицы больше не проверяется для имён таблиц запроса, если длина имени короче четырёх символов.
Если в базе данных Oracle система алиасов используется только для укорачивания текстов запросов за счёт сокращения имён таблиц до одного-двух-трёх символов, то подобное новшество можно было бы считать автоматизацией. Но поскольку у большинства групп разработки имеются свои внутренние правила, а Oracle изначально не лимитирует длину алиасов в 4 символа, то это изменение от программистов ConquestSS следует считать самоуправством. Вместо жёсткого ограничения в четыре символа стоило ввести параметр для этого правила, меньше которого оно бы не срабатывало. Проверить изменение можно проанализировав нижеприведённый код с включенной опцией "Tools / Code Audit / Code Analyzer Options / Code Review Options / The alias is missing for a table reference in a multi-source query":
select fld1, fld2 from tab1, tab2;
select fld1, fld2 from tb1, tb2;
В прошлом билде правило проверяется для обоих запросов, а в текущем только для первого, потому что имена таблиц больше трёх символов. Так что, нововведение имеется, но полный балл дать не могу.
Code Analyzer Options 0.3 из 1 возможного
* Updated the options on the Diagram Options page.
Обновлены опции на странице настроек диаграмм.
Среди заметных и конкретных изменений можно выделить те, что сменили выбор шрифтов для отображения текстов заголовков и легенд диаграмм с дополнительного стандартного диалога операционной системы на встроенные в интерфейс приложения списки фонтов и числовые радакторы для их размеров. При этом интерфейс приложения утерял полезность моментального отображения примеров выбранных параметров, а также возможность выбрать наклон и жирность шрифта. Наклон и жирность шрифта не воспринимается в текущем билде, если они были выставлены и сохранены в предыдущем. Из-за этого новшество недополучает больше полубалла.
BUGS FIXED 1+0+2.4+0+1-1+0.7+0+0.8+0+1=5.9 из 2+2+4+1+2+2+2+1+1+1+1=19 возможных, -0.4-1.5-0.5-0.5=-2.9 за баги
Core 0+1=1 из 2 возможных
* The error “TOracleObject: Invalid handle” no longer occurs on trying to get an INTERVAL attribute value from a database.
Ошибка неверного опознавателя больше не случается при попытке выбрать значение атрибута INTERVAL из базы.
Мне довольно сложно определить о чём конкретно речь, поскольку мне известны различные типы объектов, работающие с интервалами. Но каждый из них не совсем является атрибутом INTERVAL в чистом виде, потому что у колонок таблиц или переменных процедур это могут быть типы интервалов год-месяц или день-секунда, а у DBMS_JOB пакета есть процедура для обработки интервалов. Где конкретно случалась ошибка и с какого уровня атрибутом выяснить можно, но для этого придётся перелопатить абсолютно все модули приложения SD, поскольку пункт в группе Core. Невнятный текст RNs не позволяет мне отметить фикс хоть частью балла.
 |
| Редактор даты не Мастер Календаря, а Текстовый |
* Stored programs with Unicode symbols are now compiled correctly.
Хранимые подпрограммы с юникодными символами теперь компилируются правильно.
Поскольку пункт не в группе Stored Program Editor (далее - SPE), то проверки будем осуществлять не только в нём, но и в мастерах объектов, SQL Editor (далее - SE). Юникодная база позволяет наименования объектов и параметров в юникодных символах без заключения в двойные кавычки. Но нам достаточно будет юникода в комментариях кода (после части деклараций и до последнего символа в виде точки с запятой), чтобы убедиться в фиксе, касающемся только редактора, как элемента интерфейса, передающего компилятору и отображающего данные базы. Возмём любую процедуру, вставим строчку
--- русский текст
сразу после служебного слова BEGIN. Откомпилируем в SPE или SE и переоткроем в них же. Вариант "Reload from DB" не совсем приемлем в SPE для проверки фикса. Открыть хранимый объект в SE означает сгенерировать его DDL из контекстного меню объектного навигатора. Термин "корректность" в данном фиксе подразумевает передачу юникодных символов между редактором и базой с достаточной обработкой для сохранения фактических значений. Скорее всего обработки не хватало в процессе передачи юникода в базу, а не при выгрузке из базы для отображения в окне редактора. Балл заслужен полностью.
Object Navigator 0+0=0 из 2 возможных
* The error “You cannot access field data beyond Eof.” no longer occurs on trying to query collections.
Ошибка о недостижении конца списка больше не случается при попытке запросить коллекции.
В базе данных Oracle тип коллекций является частью объектных типов, а в дереве объектов SD они показываются подпапкой ноды Types. Коллекции запрашивает навигатор в дереве и списках, отображаемых в ContentSelector. Навигация на папку с коллекциями, её разворачивание и обновление не подтверждили наличие описанного бага в прошлом билде, а следственно и фикс в текущем. Поэтому балла нет.
Комплексный тест интерфейса принёс позитивную новость: в текущем билде возобновлена работа сплиттера между ContentSelector и "Scene+Dataset Managers", но не описанные в RNs фиксы не могут прибавить баллы билду.
* The database object tree is now always automatically refreshed after creating new objects in the SQL Editor and/or Stored Program Editor.
Дерево объектов базы данных теперь всегда автоматически обновляется после создания новых объектов через SQL Editor и/или в Stored Program Editor.
Поскольку у навигатора объектов давно существуют опции "Preferences / General / Object Navigator / Options / Refresh tree on object change" и "Preferences / General / Object Navigator / Options / Requery descending nodes", то описанный фикс либо действительно исправляет оплошность SD иенно при создании объектов, либо напрочь пренебрегает значениями опций. Для понимания изменений придётся создавать объекты всех 60-ти типов через редакторы кода при разных значениях двух опций и желательно сразу после запуска SD (или подключения базы) без разворачивания веток дерева в навигаторе объектов и в противовес - при развёрнутой ноде типов создаваемого объекта. Например, при одном из состояний двух опций 1) подключимся к базе, убедимся в проставлении количеств объектов у нод навигатора, в SQL Editor (не характерный мастер объектов) создадим любой объект из числа отображаемых типов, и убедимся в увеличении количества объектов без дополнительных обновлений; 2) подключимся к базе, развернём ноду со своими процедурами, убедимся в проставлении количеств объектов у всех нод навигатора, в SQL Editor создадим ещё одну свою процедуру, и убедимся в увеличении количества объектов без дополнительных обновлений и появлении новой ноды в числе процедур. Поскольку в предыдущем и текущем билдах поведение навигатора идентично для первого попавшегося типа объектов, то можно считать пункт RNs припиской. Успокою тех, кто воспринял фикс отречением функционала опций, поскольку смысл исправления должен касаться какого-то определённого типа объектов (уж и не помню точно какого, потому что мой репорт с этим багом был отправлен очень давно). Но если вы потратите немалое количество времени и отыщите конкретный тип объектов, для которого этот фикс окажется актуальным, то сможете дать балл.
SQL Editor 0+0.8+0.8+0.8=2.4 из 4 возможных
* Enabling the “Make current statement updatable” option no longer breaks formatting and cursor position.
Включение опции для перевода выражения в режим редактирования больше не сбивает форматирование и позицию курсора.
Тестирование проведём вместе со следующим пунктом RNs.
* The “Make current statement updatable” now supports Unicode.
Процедура перевода запроса в редактируемый теперь поддерживает юникод.
Во-первых, ограничим функционал для тестирования запросами SELECT и влиянием на них опции "Make current statement updatable", доступной лишь по клику одноимённой кнопки на тулбаре SQL Editor. Если в вашем наборе кнопок тулбара её нет, то добавьте её через Icon Dictionary. Для тестов нам понадобятся тексты запросов с алиасами и без них для полей и таблиц, набитые латиницей и в юникоде, с кавычками и без. Напомню, что юникодная база поддерживает имена объектов без необходимости заключать их в кавычки, а колонка ROWID добавляется в конец списка столбцов. То есть нам надо проверить примерно следующий список: 1) поля и таблица на латинице в верхнем регистре без алиасов; 2) поля и таблица на латинице в нижнем регистре без алиасов; 3) последнее поле в списке и таблица в юникоде без алиасов без кавычек; 4) ... и тому подобное. Чтобы одновременно проверять оба фикса, оставляйте курсор в конце строки перед добавлением в неё столбца ROWID. К сожалению, мне не удалось опознать изменения в форматировании и положении курсора, потому что в рамках обычной конструкции Select [список столбцов] From [список таблиц] Where [условия связки и фильтрации] запятая и через пробел служебный столбец редактирования добавляется единожды ровно между списком столбцов и служебным словом From на строке со столбцами вне зависимости от настройки "Preferences / Code Editors / Display / Margin and Gutter / Width", а курсор перестаёт моргать, оставаясь на своей позиции, после перерисовки фолдингов на левом поле редактора и спустя три секунды в обоих билдах одинаково. А вот поддержка юникода обнаружилась как для имён в кавычках, так и для прямых наименований таблиц и полей. Поэтому только один из фиксов получает балл, но не полный из-за необходимости пояснений.
* The Variables Manager now remembers the type of REF_CURSOR variable.
Мэнеджер переменных теперь запоминает тип переменной REF_CURSOR.
Стоит уточнить, что речь идёт о закладке "Bind and Subst Variables" и её опции "Preferences / Code Editors / Bind and Subst. Variables / Remember variables". А тесты проведём совместно со следующим пунктом RNs.
* Viewing the REF_CURSOR variable value no longer causes errors.
Просмотр значения переменной ссылочного курсора больше не сопровождается ошибкой.
Для тестов создадим таблицу с данными и пакетную функцию:
CREATE TABLE EMPS (enum NUMBER(6,0) NOT NULL, ename VARCHAR2(20) NULL, job_id VARCHAR2(10) NOT NULL );
INSERT INTO EMPS(enum, ename, job_id) VALUES (1001, 'name first', 'depart_1');
INSERT INTO EMPS(enum, ename, job_id) VALUES (1002, 'name second', 'depart_2');
INSERT INTO EMPS(enum, ename, job_id) VALUES (1003, 'name third', 'depart_3');
--- последующая команда создания объекта автоматически закоммитит данные в таблицу
CREATE OR REPLACE PACKAGE sqlj_refcursor AS
TYPE EMP_CURTYPE IS REF CURSOR;
FUNCTION job_listing (j varchar) RETURN EMP_CURTYPE;
END sqlj_refcursor;
/
CREATE OR REPLACE PACKAGE BODY sqlj_refcursor AS
FUNCTION job_listing (j varchar) RETURN EMP_CURTYPE IS
rc EMP_CURTYPE;
BEGIN
OPEN rc FOR SELECT ename, enum FROM emps WHERE job_id LIKE j;
RETURN rc;
END;
END sqlj_refcursor;
/
Далее в окне редактора кода SQL Editor наберём исполняемый блок с переменными:
BEGIN
:RESULT := SQLJ_REFCURSOR.JOB_LISTING('d%');
END;
На закладке "Bind and Subst Variables" выполним сканирование переменных, включим опцию "Preferences / Code Editors / Bind and Subst. Variables / Remember variables" и выключим опцию "Preferences / Code Editors / SQL Editor / SQL Output / Display / Bind variables". При запуске блока исправим тип переменной RESULT на "REF Cursor" и OUT. После исполнения блока попытаемся просмотреть значения переменной RESULT, кликнув по её ячейке на закладке "Bind and Subst Variables". Вне зависимости от включенности опции "Smart output", расположенной справа от всех закладок с выводом результатов, автоматически активируется SQL Output закладка с ошибкой "ORA-00900: invalid SQL statement" и списком переменных без их значений. Повторив попытку просмотра значений переменной в вывод попадут и список переменных, и их значения, но уже без ошибки базы в прошлом билде. В текущем билде значения переменных и их список выводятся при первом же запросе и без ошибки базы. Это подтверждение правки. Повторный запуск блока с включенной опцией "SQL Editor / Bind and Subst Variables / Prompt variables before execution" или сканирование переменных блока после перезапуска SQL Editor (или даже SD) покажет, что тип переменной REF Cursor действительно стал запоминаться в текущем билде, а не присваивает по-умолчанию запомненной переменной строковый тип. Но поскольку мне пришлось пояснять конкретику исправлений, то оба пункта получают не полные баллы.
Stored Program Editor 0 из 1 возможного
* An access violation error no longer occurs on entering text in the overwrite mode.
Ошибка доступа больше не случается при вводе текста в режиме перезаписи.
Редакторы кода могут работать в двух режимах - вставки и перезаписи, которые переключаются по нажатию клавиши INS или кликом по соответствующему индикатору на статусной строке приложения. Прошу не путать со статусной строкой редактора, информация на которой отсутствует при первом открытии пустого редактора и появляется после переключения режима. Мне никак не удалось воспроизвести описанную ошибку, поэтому пункт RNs считаю припиской и не даю ни балла. Благосклонно не снимая баллов за отсутствие первоначальных статусов.
Code Insight 0+1=1 из 2 возможных
* Identifiers are now correctly selected on a double-click.
Идентификаторы теперь правильно выбираются по двойному клику.
* Unicode identifiers are now correctly selected on a double-click.
Юникодные идентификаторы теперь правильно выбираются по двойному клику.
Оба фикса будем проверять единым тестом, поскольку их довольно просто объединить.
Для теста откроем текст хранимой подпрограммы с идентификаторами (имена подпрограмм и параметров), названными обычными латинскими символами (не забудьте про вариации с цифрами и разрещёнными служебными символами доллара, рещётки) и юникодными (в юникодной базе позволительно без двойных кавычек) в Stored Program Editor, SQL Editor или редакторах кода, встроенных в мастера объектов (на языке Delphi этот компонент называется SynEdit и поддерживает работу модуля Code Insight). В чём стала заключаться корректность выделения обычных идентификаторов, мне не удалось выяснить. Заметным стало лишь полное выделение юникодных имён по двойному клику. Поэтому балл зарабатывает только один из двух фиксов.
Smart Dataset 0-1=-1 из 2 возможных
* The error ORA-06553 no longer occurs on trying to update a table having two columns with the same object datatype.
Ошибка базы больше не случается при апдейте таблицы с двумя столбцами одинакового типа.
Из документации DB Oracle выясняем, что ошибка "ORA-06553: PLS-string: string" означает наличие проблемы при работе с символьным параметром. Значит можно предположить, что одинаковыми типами полей должны быть какие-то символьные поля: VARCHAR, NVARCHAR, CHAR, NCHAR, CLOB, NCLOB, LONG. Тип LONG исключим, потому что в таблице может быть только одна такая колонка, согласно ограничениям базы. Ещё к этим вариациям придётся добавить возможность измерения строк в байтах или символах, о чём в баге не упомянуто: оба поля в байтах/символах или разноразмерные? Да и про величину полей (одинаковые оба или разные, максимальная/минимальная/средняя) тоже не упомянуто. A/B-тестирование для этого бага в его нынешней интерпретации никак не подходит, обязательно придётся проверять абсолютно все комбинации. Если вы владеете TestComplete, как единственным средством автоматизации продукта, написанного на Delphi с самописными интерфейсными элементами, то вполне быстро напишите и автотест: в SQL Editor выполнить скрипт на удаление и создание таблицы (скрипты на каждую вариацию столбцов можно хранить в тестовой базе - обычная файловая система), открыть таблицу в SmartDataset, добавить строки и отредактировать эти данные интерфейсными средствами (данные для ввода и редактирования хранить в связке со скриптами на создание таблицы), отслеживать наличие и отсутствие ошибок базы. Мои тесты не смогли показать конкретную причину бага и вообще хоть как-то воспроизвести баг. Поэтому не могу считать фикс сделанным и дать хоть сколько-нибудь баллов. Из положительных моментов могу отметить небольшое интерфейсное исправление: при добавлении строк в полностью пустую таблицу нумерация строк не дублирует единицу в первых двух записях. Но за неописанные в RNs изменения билд не может получить дополнительные баллы.
* Fixed counting of new lines in a table.
Исправлен подсчёт новых строк в таблице.
Модуль SmartDataset доступен в нескольких местах:
- самостоятельно из главного меню "File / New / SmartDataset" или "Object Browse";
- как часть других модулей Table Wizard, View Wizard, Materialized View Wizard, Object Navigator, SQL Editor в режиме редактирования данных и в множестве других в режиме просмотра данных.
Поскольку в баге речь идёт о новых строках, значит набор данных должен быть в открытом режиме на редактирование:
- достаточно прав на объект базы (гранты, констрейнты, триггеры);
- нет ограничений на редактирование данных в SD (выключена опция "Preferences / General / Data Protection / Enable data protection" для подключенной сессии);
- нет ограничений при выполнении запросов "Preferences / Code Editors / SQL Editor / SQL Execution Wrapper";
- в SmartDataset выключен режим "Read-only Mode" = кнопка с замочком на тулбаре или одноимённый пункт в главном и контекстном меню Dataset);
- запрос выполнен в грид с полем ROWID (актуально для SQL Editor или Query Builder).
После проверки предварительных установок сделаем сами данные для проверки: возмём любую "свою" таблицу и будем подсчитывать строки в ней после добавления очередной строки. Поскольку в баге речь о новых строках, то напомню способы их добавления:
- кнопка на тулбаре или пункт контекстного и главного меню "Dataset / Insert Record";
- горячая клавиша - INS;
- дойти до конца строк и нажать стрелку вниз;
- импортировать через Import Data Wizard;
- выполнить insert-скрипт с коммитом в SQL Editor или любом ином аналогичном приложении.
Пустые добавленные строки первыми двумя способами не учитывались и не учитываются в подсчёте строк (кнопка на тулбаре или пункт меню "Dataset / Count Records"). Непустые добавленные строки учитывались и входят в сумму строк даже без коммита в базу. Новые строки, добавленные через внешние средства, по прежнему учитываются без рефреша грида, что фактически можно считать интерфейсной недоработкой, потому что нет предложения юзеру обновить набор данных при не совпадении отображённого видимого количества строк с подсчитанным базой. Мои тесты показали, что фикс сделан точно в обратную сторону: диалог для показа количества подсчитанных строк обрезает значение после первого символа, то есть вместо 1000 показано 1, вместо 200 - 2. Поэтому пункт RNs отнимает -1 балл у билда.
Database Connection Window 0+0.7=0.7 из 2 возможных, -0.2-0.2=-0.4 за баги
* Sorting of database connections is now correctly restored after restarting the application.
Сортировка коннектов к базе теперь правильно восстанавливается после перезапуска приложения.
В предыдущих версиях SD быстро выставить сортировку по нескольким столбцам было возможно обычными кликами по заголовкам. Теперь быстро выставляется и меняется сортировка только одного поля. Но функционал вынесен в контекстное меню каждого заголовка. Тесты проведём как для простой сортировки, так и составной. Для формирования данных нам будет достаточно одной базы (в файле настроек TNS добавить несколько имён с одинаковыми параметрами, а часть коннектов производить Direct способом) и нескольких разноимённых (обычные латинские, малые буквы в двойных кавычках, имена с цифрами и другими знаками) схем в ней. Для разных дат в тестовом наборе можно переводить дату на компе, но только в рамках триального периода. Если бы вы были внутренними тестировщиками, то можно было бы дать вам ветку реестра с множеством различных коннектов, накопленную за многие годы работы в ConquestSS. По-умолчанию, список последних коннектов сортируется по дате-времени. Значения в этом столбце фактически всегда уникальны, а порядок сортировки в предыдущем и текущем билдах идентичен. Так что ничего с точки правильности заметить не получится. Поэтому выставим сортировку по имени базы или имени пользователя, но только по одному полю. Разница в списках билдов видна, но не понятна. Не могу утверждать, что к сортировке по базе добавляется сортировка по дате, поскольку это и фактически не так, и не подпадает ни под какие правила. Также различны получаются сортировки при запуске приложения или переоткрытии окна в случае сортировки по имени схемы. Сортировки по двум-трём полям в обоих билдах одинаковы. Результат тестов не утешителен - балл дать не за что. А за выявленный сопутствующий баг - автофит по direct-коннектам не полностью подсчитывает количество знаков в имени базы - сниму -0.2 балла.
* The username and password fields are no longer empty when the Database Connection Window is automatically opened after the startup window.
Имя пользователя и пароль теперь не пустые, когда окно коннектов автоматически открывается после окна старта.
Чтобы при старте приложения появлялось окно старта, надо включить опцию "Preferences / General / Show startup window" и перезагрузить SD. Окно старта можно закрыть четырьмя способами: нажав одну из больших кнопок "Last connection", "Recent connections", "Connect to..", кликнув по крестику в правом верхнем углу окна или нажав сочетание клавиш Alt+F4 (в Windows стандартый набор для закрытия активного окна). Вариант закрытия модального окна по привычному нажатию на клавишу ESC здесь не работает и создаёт у юзера впечатление неполноценности интерфейса. Кнопка "Last connection" закрывает старт-окно, но без показа последних коннектов продолжает работу приложения. Кнопка "Recent connections" имеет стрелочку для раскрытия списка, но он разворачивается не по клику стрелочки, а в любом другом месте кнопки. То есть функционал интерфейса работает неожиданным для юзера образом, но об этом нигде не сказано и не приведено к общепринятому стандарту. А после клика по одному из последних коннектов окно старта закрывается без показа списка коннектов в окне "Database Connection Window" и ПО продолжает обычную свою работу. То есть вышеперечисленные варианты не соответствуют исходному багу. Клик по кнопке "Connect to.." закрывает старт-окно и открывает "Database Connection Window", позиционированное на последнем коннекте и все поля заполнены. И только клик по крестику в правом верхнем углу окна (или нажав сочетание клавиш Alt+F4) открывал "Database Connection Window" с пустыми полями юзера и пароля в прошлом билде. Мелочь, не указанная тех.писательницей в описании бага, отняла у тестировщика время на воспроизедение, а юзера запутала в функционале. За это фикс недополучает часть балла. Отдельно за юзабилити проблему снимаю -0.2 балла.
Database Connection Options 0 из 1 возможного
* A confirmation message no longer appears on closing the Connection Options window when no Microsoft Visual Studio Redistributable Package is selected.
Подтверждающее сообщение больше не появляется на закрытии окна опций подключения к базе, когда пакет Microsoft Visual Studio Redistributable не выбран.
Некоторые модули SD не могут работать без установленного пакета Microsoft Visual Studio Redistributable особой версии, поэтому разработчики включили его в свой инсталлятор. Но если юзер решил поработать на другой машине, а не запускал инсталлятор, лишь скопировав SD себе на диск или того проще - запускает программу с сетевого диска, то возможен вариант, когда на рабочей машине отсутствует необходимый пакет. Почему сами разработчики не проверили все места, где идёт обращение к пакету - вопрос к их отделу тестирования. А ведь чего проще - запустить поиск по всем исходникам кода на обращения к стандартному пакету, построить схему SD или выписать список мест в таблицу и затем по подобному чек-листу пройтись в продукте после стандартной установки и иных способах запуска продукта. В рамках тестирования обращений к уже установленному системному пакету не будем рассматривать правовые нормы, позволяющие включать чужие продукты в свой. Это стоило рассматривать в рамках тестирования инсталлятора и иных тестов по безопасности. В данном случае характер тестов направлен на доступность и юзабилити, потому что в окне с опциями подключения к базе стала показываться информация о дополнительных установках, но по-видимому были забыты некоторые случаи. Итак, чтобы увидеть убранное сообщение вероятно нам достаточно деинсталлировать пакет и открыть, закрыть окно настроек коннекта по кнопке Options окна Oracle Database Connection. В OS Windows через утилиту удаления программ деинсталлируем пакет Microsoft Visual Studio Redistributable. Но открыв опции коннектов в SD или "Help / System Information" удивительным образом обнаруживаем, что пакет всё ещё инсталлирован. Такое поведение продукта говорит о наличии блокера системного характера, не позволяющего проверить текущий фикс, потому что наличие инсталляций пакета MS считывает данные не из операционной системы. Поскольку невозможно воспроизвести баг в предыдущем билде, значит также невозможно в текущем билде увидеть фикс. Так что, этот пункт RNs не получает ни балла. Пожалею разработчиков и не сниму балл за странное определение инсталляций сторонних пакетов.
Export and Import Wizard 0.8 из 1 возможного, за баги -1.5
* Data export from a table with timestamp columns no longer causes errors.
Экспорт данных из таблицы с колонками типа timestamp теперь проходит без ошибок.
Для теста создаём таблицы с одним и несколькими столбцами типа TIMESTAMP:
CREATE TABLE TMSTMP1 (COL1 TIMESTAMP NULL)
/
CREATE TABLE TMSTMP2 (COL1 TIMESTAMP NULL, COL2 TIMESTAMP NULL)
/
CREATE TABLE TMSTMP3 (COL1 TIMESTAMP NULL, COL2 NUMERIC NULL)
/
В каждую вставляем по паре-тройке записей через мастер календаря. И пытаемся экспортировать из них данные всеми доступными типами - от скрипта до встроенного. Тесты в предыдущем билде показали, что все способы экспорта, кроме Excel и внутреннего форматов, прерывались на значениях TIMESTAMP-полей с размерностями секунд, не равными нулевым. То есть тех.писательница не уточнила смысл бага, а значит запутала пользователя. За что пункт RNs недополучает полный балл.
В рамках комплексного тестирования обнаружились баги, как в мастере экспорта, так и в других модулях при работе с типом поля TIMESTAMP:
1. Лог мастера экспорта данных не для всех оборванных выгрузок оставляет записи красного цвета. Например, в HTML или XML форматы.
2. Записи в логе экспорта о проблемных данных не имеют пробела между текстом ошибки и маркером Failed. Это характерно для SQL, TXT форматов.
3. При экспорте в Excel шаги мастера стали подвешивать интерфейс, а количество экспортированных по факту строк не совпадает с показанными в логе.
4. Проблема конвертации осталась актуальна для Access-типа экспорта.
5. Фактические значения долей секунд видны только в мастере календаря, но не отображаются в SmartDataset и SQL Output, не выгружаются ни в один из типов экспорта данных. В SmartDataset после обновления данных из базы (прошу не путать с обычным Refresh - F12) пропадают из видимости даже нулевые доли секунд.
6. Импорт благополучно, хоть и без долей секунд, проходит только из двух типов - Excel и INSERT-скрипт. Остыльные валятся на конвертации в TIMESTAMP.
В общей сложности баги тянут на -1.5 балла.
PL/SQL Debugger 0 из 1 возможного, -0.5 за баг
* Breakpoints now work correctly after an Oracle exception is raised.
Точки останова теперь работают корректно после срабатывания исключений базы.
Работу отладчика можно посмотреть только в Stored Program Editor, поэтому в нём откроем любую хранимую подпрограмму, откомпилируем её с дебаговой инфой, поставим точки останова в разных местах и позапускаем отладчик. Поскольку фикс конкретизирует только оракловые исключения, то возмём из документации по базе Oracle такой код:
DECLARE
default_number NUMBER := 0;
BEGIN
INSERT INTO t VALUES(TO_NUMBER('100.00', '9G999'));
EXCEPTION WHEN INVALID_NUMBER THEN DBMS_OUTPUT.PUT_LINE('Substituting default value for invalid number.');
INSERT INTO t VALUES(default_number);
END;
Точки останова будем выставлять на строках, которые выполняются после исключения. Тесты в предыдущем и текущем билдах не показали никакой разницы при работе дебаггера в рамках Stored Program Editor. Поэтому пункт RNs остаётся без баллов. Случайно пойманная проблема конвертации числовых и символьных на 13327[8] строке метода "TOracleQuery.FieldAsInteger" вынуждает меня снять с билда -0.5 балла.
Database Monitor 1 из 1 возможного, -0.5 за баги
* Connecting to a new database no longer clears the session drop-down list in the Database Monitor.
Коннект к новой базе больше не очищает список ранее подключенных сессий в модуле.
Утилита мониторинга базы мультисессионная, то есть одно окно может работать с несколькими подключенными сессиями баз, переключая их не в главном меню или тулбаре приложения, а непосредственно в окне DB Monitor.
При подключении новой сессии базы в SD список коннектов в мультисессионных модулях должен пополняться, а в текущем активном окне ещё и перевыбираться на только что подключенную базу.
Монитор базы можно стартовать на сбор статистики в одной базе и в это же время подключиться в рамках приложения к другой базе.
Так что тест проведём в следующих вариациях:
1) окно DB Monitor открыто, но не активно и процесс сбора статистики не запущен;
2) окно DB Monitor открыто, процесс сбора статистики запущен, но активно иное окно приложения;
3) окно DB Monitor открыто, процесс сбора статистики запущен и активен рабочий модуль.
При каждом сочетании будем подключать новую сессию обычного пользователя и администратора базы. Во всех случаях, когда окно DB Monitor являлось активным на момент подключения новой сессии, список сессий этого модуля (комбобокс) очищался в предыдущем билде.
К тому же подмечено, что фактически добавленные, но не активированные новые сессии, да и те добавленные сессии, когда модуль не был активен, не имели нумерацию, как это показывается, например, в главном комбобоксе сессий и навигаторе объектов.
Из положительного: размер комбобокса в модуле меняет свою ширину для полного отображения наименования подключения, после перезапуска модуля все подключенные сессии названы идентично главному списку.
В рамках комплексного тестирования обнаружено, что сбор статистики не останавливается при смене сессий. Это приводит к тому, что файлы с накопленными данными неожиданно создаются для только что подключенных баз, а история прерывается или разбивается по имени коннекта, но это никак невозможно понять, потому что в истории не отображается имя подключенного пользователя, да и в имени файлов указано только имя базы (TNS и DIRECT варианты одной и той же базы считаются разными). Процесс сбора статистики не прекращается даже при отключении всех баз от приложения. Если в процессе сбора на некоторых графиках имеются сообщения о нехватке прав обычного юзера, то в истории нет никаких разъяснений для пустых графиков. К тому же не совсем возможно прочесть предупреждения в только открывшейся закладке историй о необходимости выбрать период для загрузки из дерева историй.
Фикс получает балл, а за давнишние баги, вновь привлекшие внимание, сниму -0.5 балла.
В итоге билд готов на (4.5+5.9)/(12+19)~55% и теряет -0.5-2.9=-3.4 балла из-за багов.
