Проверьте сценарий sql действительным

Question

В рамках выпуска мы запускаем загрузку сценариев PL / SQL для базы данных. Недавно кто-то оставил ; в конце строки в одном сценарии, который назывался другим сценарием, так что это означало, что сценарий не запустился. Поскольку это не вызвало ошибки, оно просто не запустилось, потребовалось много времени, чтобы отследить, что произошло.

Я хочу проверить сценарии перед их выполнением на наличие строк в них, в которых отсутствует либо ; в конце, либо / в строке после. Это усложняется тем, что «строки» в скрипте могут фактически занимать более одной строки, если это оператор или блок кода.

Мне кажется, что для этого мне нужно разобрать сценарии, а затем проверить, соответствуют ли они выше.

Я нашел ANTLR и задаюсь вопросом, может ли это быть способом сделать это, поскольку, кажется, существует существующих грамматик PL / SQL , но похоже, что это будет шагом Кривая обучения для простой проверки.

Кто-нибудь знает простой способ или какие-либо другие инструменты, плагины затмений и т. Д., Которые я могу использовать для проверки строк в сценариях, в которых отсутствует либо ; в конце, либо / в строке после?

Обновление Мы уже делаем большую часть материала Том Х предложил . Сценарии запускаются на нашем тестовом сервере, и у нас есть таблица версий, которая обновляется в конце. Проблема заключалась в том, что пропущенная точка с запятой в сценарии контейнера означала, что один сценарий не был запущен, но остальные, включая тот, который обновлял номер версии, работали без ошибок. Поэтому проблема только попала в тестирование. Это требовало восстановления базы данных перед запуском сценариев с добавлением отсутствующей точки с запятой, что в основном приводило к потере полдня времени тестирования. Если бы был простой способ проверить это до запуска скриптов на тестовом сервере, это могло бы сэкономить немало времени.

Answer 1

Я согласен с Мэттом, что вы можете поступить неправильно. Я бы просто добавил оператор вставки в конец всех ваших сценариев, которые вставляют строку «версия» в таблицу в базе данных. В конце сценариев развертывания легко проверить, что в таблице версий есть все правильные строки.

Кроме того, все ваши сценарии выпуска должны запускаться в точности так, как они будут работать на вашем сервере QA. Вот где все испытания проводятся. Вы никогда ничего не делаете с сервером, кроме того, что находится в ваших шагах по выпуску - вы только запускаете сценарии выпуска, и если эти сценарии выпуска когда-либо изменяются, вы обновляете ими сервер QA и повторяете тестирование.

Когда вы отправляетесь в производство, ваш процесс выпуска был полностью протестирован. В качестве отказоустойчивой меры вы также можете использовать такие инструменты, как SQL Gate от Red Gate и SQL Data Compare для проверки соответствия производства QA-серверу. Сравнение данных будет проводиться только для определенных таблиц (справочных таблиц и т. Д.). Если у вас есть изменения данных в основных таблицах (1М строк и т. Д.), Вы можете исправить собственный сценарий, чтобы убедиться, что они верны.

Answer 2

Даже если сценарии различны для каждого выпуска (и не являются частью определенной структуры управления исходным кодом, которая создает или заменяет объекты базы данных), я бы применил практику разбиения сценариев на наиболее фундаментальные единицы работы для каждого файла и развертывания их через Ant со стандартной задачей sql. Возможно, у вас есть следующие типы сценариев:

• СОЗДАТЬ или ЗАМЕНИТЬ объект dbob ...
• SQL DML-скрипты
• Анонимные блоки PL / SQL

Если вы стандартизуете согласованный разделитель операторов (я предлагаю использовать «/», так как он работает во всех вышеупомянутых случаях) и установите развертывание как ошибочное при развертывании, то Ant либо развернет все файлы, либо укажет, почему не мог.

Я думаю, что было бы очень сложно иначе проанализировать файлы одного или нескольких операторов SQL и / или PLSQL и найти пропущенные разделители, если нет стандартов выбора или операторов разделителей для файла.

Answer 3

Просто мысль, а вы идете по этому поводу неправильно?

Я предполагаю, что на уровне файлов отсутствие точки с запятой в файле не было проблемой? но это только стало проблемой при запуске через пакетную обработку? Если это так, возможно, вы можете изменить свою пакетную обработку, чтобы справиться с этим.

Если это был файл, то тестирование должно было подхватить его. Вы не хотите анализировать входные файлы, чтобы убедиться, что они компилируются и т. Д.