poor mans t sql formatter npm cli
1.0.0
Средство форматирования SQL с командной строкой, которое работает практически в любой среде (при условии, что установлен node.js).
Он основан на пакете NPM Poor Man's T-SQL Formatter (poor-mans-t-sql-formatter), который, в свою очередь, основан на одноименной библиотеке C# (https://github.com/TaoK/PoorMansTSqlFormatter). ).
Это средство форматирования должно быть эквивалентно по функциональности средству форматирования командной строки C#, которое существует уже несколько лет (можно загрузить по адресу http://architectshack.com/PoorMansTSqlFormatter.ashx), с двумя основными отличиями:
Его очень легко установить, особенно в Unixey-средах, если доступен Node.js.
Это немного медленнее, чем форматтер на базе .Net.
(при условии, что node.js установлен)
npm install --global poor-mans-t-sql-formatter-cli
Ввод по конвейеру/стандартному вводу и вывод стандартного вывода:
echo "select a from b join c on b.id = c.id where abc = 123 and def = N'whatêver' " | sqlformat
ввод и вывод файлов:
echo "with a as (select 1 as b) select * from a cros join c" > testfile.sql sqlformat -f testfile.sql -g testfile.sql cat testfile.sql
Этот форматировщик командной строки завершит работу с кодом завершения, отличным от 0, если при синтаксическом анализе SQL «возникнут проблемы» - например, если он встретит незавершенный оператор «IF», предполагающий, что что-то в SQL не было правильно понято/проанализировано, и поэтому может «выйти не так». Существует возможность отключить это поведение, если известно, что SQL сомнительный или путаница при синтаксическом анализе безобидна.
Если синтаксический анализ прерван, любой указанный «выходной файл» останется нетронутым.
Параметры, специфичные для утилиты командной строки:
| Вариант | Описание | Тип | По умолчанию |
|---|---|---|---|
| --inputFile | Чтение входных данных, которые будут отформатированы из файла, а не из стандартного ввода (типизированный или конвейерный ввод) | нить | |
| --outputFile | Запись форматированного вывода в файл — как перенаправление оболочки стандартного вывода, за исключением ошибки, при которой файл остается нетронутым. | нить | |
| --ignoreErrors | Вернуть код выхода 0 (успех), даже если синтаксический анализ не удался (и поэтому форматированный вывод является подозрительным) | логическое значение | |
| --inputEncoding | Используйте для ввода определенную кодировку символов, поддерживаемую узлом — в основном utf-16le или utf-8. | нить | utf-8 |
| --outputEncoding | Используйте для вывода определенную кодировку символов, поддерживаемую узлом — в основном utf-16le или utf-8. | нить | utf-8 |
| --forceOutputBOM | Добавьте метку порядка байтов (BOM) в начало вывода. | логическое значение |
Стандартные параметры форматирования:
(обратите внимание, что логические параметры, которые обычно по умолчанию имеют значение «истина» в библиотеке, были заменены префиксом «нет», следуя соглашениям о параметрах командной строки Unixey)
| Вариант | Описание | Тип | По умолчанию |
|---|---|---|---|
| --отступ | Единица отступа — обычно табуляция (t) или количество пробелов. | нить | т |
| --maxLineWidth | Попросите форматировщик переносить длинные строки, чтобы избежать превышения этой длины строки. | интервал | 999 |
| --spacesPerTab | Это используется для измерения длины строки и применяется только в том случае, если вы используете табуляции. | интервал | 4 |
| --statementBreaks | Сколько разрывов строк следует добавить при запуске нового оператора? | интервал | 2 |
| --clauseBreaks | Сколько разрывов строк следует добавить при начале нового предложения в инструкции? | интервал | 1 |
| --no-expandСписки запятых | Следует ли разбивать списки, разделенные запятыми (столбцы, группы по аргументам и т. д.), на новые строки? | логическое значение | |
| --no-trailingЗапятые | При запуске новой строки из-за запятой должна ли запятая находиться в конце строки (а не в начале следующей)? | логическое значение | |
| --spaceAfterExpandedComma | Стоит ли ставить пробел после запятой? (обычно нет, если они «отстают») | логическое значение | |
| --no-expandBooleanExpressions | Должны ли логические операторы (И, ИЛИ) вызывать разрыв строки? | логическое значение | |
| --no-expandCaseStatements | Следует ли в выражениях CASE разбивать выражения WHEN и THEN на новые строки? | логическое значение | |
| --no-expandBetweenConditions | Должен ли в выражениях BETWEEN максимальный аргумент переноситься на новую строку? | логическое значение | |
| --expandInLists | Должны ли списки IN() содержать каждый аргумент на новой строке? | логическое значение | |
| --breakJoinOnSections | Следует ли вынести раздел ON предложения JOIN на отдельную строку? | логическое значение | |
| --no-uppercaseКлючевые слова | Должны ли ключевые слова T-SQL (например, SELECT, FROM) автоматически записываться в верхний регистр? | логическое значение | |
| --keywordСтандартизация | Следует ли заменить менее распространенные ключевые слова T-SQL их стандартными аналогами? (ПРИМЕЧАНИЕ: безопасно только для T-SQL!) | логическое значение |
Параметры форматирования (команда «min»):
| Вариант | Описание | Тип | По умолчанию |
|---|---|---|---|
| --randomizeKeywordCase | Следует ли рандомизировать регистр ключевых слов, чтобы минимизировать читаемость? | логическое значение | |
| --randomizeLineLengths | Следует ли переносить SQL-код через произвольные промежутки времени, чтобы минимизировать читаемость? | логическое значение | |
| --no-preserveКомментарии | Следует ли сохранять комментарии в коде (а не удалять их)? | логическое значение | |
| --enableKeywordSubstitution | Должны ли ключевые слова с синонимами использовать менее распространенные формы? (ПРИМЕЧАНИЕ: безопасно только для T-SQL!) | логическое значение |
Обратите внимание: этот инструмент командной строки в настоящее время НЕ выдает вывод в формате HTML (с выделенным синтаксисом). Добавить эту функцию было бы достаточно тривиально, она определенно поддерживается базовой библиотекой, но я не видел ни одного реалистичного варианта использования. Если он у вас есть, дайте мне знать (и/или развилку, добавьте опцию(и), дайте мне знать).
Этот форматтер эффективно «наследует» все функциональные возможности библиотеки форматирования T-SQL Poor Man's:
Полная поддержка MS SQL Server T-SQL без (насколько мне известно) ошибок синтаксического анализа ** Включая полную поддержку процедурного/пакетного кода, DDL, DML и т. д.
Разумная поддержка других диалектов SQL (регулярно используется для форматирования запросов PL/SQL, PostgreSql, MySQL и т. д.) ** Конкретные конструкции могут не работать или могут некорректно/достоверно сохраняться для этих других диалектов. Сообщайте о проблемах при обнаружении таких проблем.
Разумное количество параметров конфигурации форматирования, и их будет больше.
Как отмечено в документации пакета библиотеки JS (https://github.com/TaoK/poor-mans-t-sql-formatter-npm-package), на данный момент этот форматтер работает довольно медленно . На моем ноутбуке форматирование одного запроса занимает около полсекунды. Это говорит о том, что для рабочих нагрузок массового форматирования может иметь смысл предложить опцию подстановочного/рекурсивного ввода/вывода файлов.
Поддержка кодировки также очень ограничена — поскольку мы используем встроенную поддержку кодировки узла, она сводится к utf-8 или utf-16le. Возможно, стоит решить эту проблему с помощью библиотеки iconv-lite, но добавление еще большего количества кода для загрузки также будет иметь свои недостатки. Есть о чем подумать.
Помимо этих вещей, мне не известны какие-либо серьезные нерешенные проблемы (по сравнению, например, с версией C#/.Net того же средства форматирования командной строки, которую можно загрузить по адресу http://architectshack.com/PoorMansTSqlFormatter.ashx), поэтому любые входные данные/функции запросы приветствуются!
