PSV100Максим НПонятно, что сейчас там нет проверки на комментарии и возможно множество других нюансов, но зато прозрачно и просто.
Может и просто, но не функционально. Раз уж вспомнились текстовые редакторы, то продолжу эту линию.
Посмотри на SublimeText, на его правила задания синтаксиса. Там есть понимание некоего "scope", т.е. области кода. Хорошая штука, имхо, можно от неё плясать. Имеющиеся типовые метки кода (для goto symbol) предназначены, в основном, для того, чтобы прыгнуть в тексте на начало участка, например, на заголовок процедуры, а вот где конец этой процедуры, как правило, этим меткам не важно.
Далее посмотри на JEdit. У него есть мощные парсеры кода, которые можно от него оторвать (вроде бы, я как-то видел какой-то проект, где было сказано, что используется разбор от JEdit, не помню точно, может быть это был тоже какой-то велоредактор. Лицензия вроде позволяет, а если поделиться своими доработками, то всем только лучше будет). У него правила для синтаксиса задаются по мотивам эмаксовых mode, кроме регулярок есть и другие способы. Имеется взаимосвязь между mode. Например, если при разборе html встречается код на javascript, то можно указать, что разбором javascript-а будет заниматься соответствующий mode. Или можно задать ряд общих правил, например, разбор комментариев, а в других mode их подмешивать. Но вот явных scope кода вроде как нет. Не помешало бы их добавить, причём реализовать правила корректного определения границ области. Например, чтобы определить границы "begin-end" всего блока кода как тела процедуры, нужно игнорировать или понимать внутренние вложенные области с "begin-end", которые используются внутри sql-операторов (или прочие "end" как "if-end"). Короче говоря, есть реальный потенциал для задания правил разбора SQL, под разные диалекты.
Посмотри на плагины
SQL и
PelczarSql . Там есть примеры организации конфигурируемой системы для работы с метаданными для разных СУБД. Обращаю внимание, что у плагина "SQL" есть концептуальный недочёт - он подразумевает, что у сервера СУБД на самом верхнем уровне есть система всяких "schema" или пользователей как "owner" объектов и т.п. Это не всегда так, у sqlite, FireBird и др. не имеют явных "schema" (точнее, они по-другому управляются). Ну, и там есть примеры организации работы с сервером для выполнения sql-запросов и скриптов. Есть дополнительные плюшки, например, извлечение параметров для sql-запроса из комментариев. Есть примеры парсеров для разбивки текста на отдельные sql-команды, ну и куча всего.
Итого, можно задать правила для разбора sql-исходников, под разные диалекты. Связать синтаксические правила с системой метаданных для каждой СУБД, плюс задать правила для логики построения БД, т.е. очередность создания элементов. Это уже реальная почва для универсальных выкрутасов. Тогда от пользователя, фактически, нужны лишь правила для именования объектов согласно потребностям проекта.
Далее, можно это дело подкрепить функционалом от плагина
Beauty - форматирование кода на основе тех же универсальных парсеров для синтаксического разбора (а также там для ряда языков отдельный семантический анализ).
Ну а для манипулирования исходниками можно приспособить
Fossil . Он все данные хранит внутри одной sqlite-базы, причём это не только система контроля версий, но и багтрекер с вики в одном флаконе не отходя от кассы. Взаимодействие с git-ом у него из коробки. Можно дополнить fossil-базу своими таблицами, куда помещать разобранные sql-исходники. Через обычный SQL получаем возможность лепить sql-скрипты на любой чих, к тому же используя СКВ и т.д. Думаю, фантазия понятна.
Таким образом, необходимо спроектировать правила для разбора SQL, задать правила для манипулирования метаданными из БД, и дать простор для пользователя "селектить" себе нужные sql-скрипты - это и есть мечта конечного пользователя. Ему для своего проекта достаточно задать шаблоны для именования объектов и настроить предпочтения для форматирования. Далее подавай на вход любые sql-скрипты и затем извлекай любые результаты, подкреплённые версиями, плюс документация с требованиями/задачами по проекту.
Ещё нужно подумать над комментариями. Внутри блоков комментарии сохраняются как есть. Для исходных sql-скриптов можно задать требования, задающие привязку комментариев к участкам кода, например, многострочные "/* ... */" - предшествуют целевому объекту/коду, "-- ..." - после. Нужно выделять комментарии-доки (дополнительная звёздочка и как "--- ..."). Кроме документации там будут опции/аннотации для сборки и т.п. А также через них можно определять или идентифицировать анонимные блоки кода для исполнения (при создании/накатов).
Плюс нужны заготовки для "селектов" с целью формирования указаний для миграторов. В том числе, нужно предусмотреть выборку конкретных sql-операторов и прочих операций, чётко заданных в явной последовательности. Не помешал бы и какой-то придворный мигратор, раз уж такая пьянка. И, в целом, можно не только формировать скрипты, но и исполнять тут же.
Это уже какая-то реальная IDE. Возможно, это даже основа для дальнейшего развития всей жаба-инфраструктуры, как развитие компонентной технологии и аспектного программирования, плюс задатки для моделирования :))
В общем, рекомендую по утрам подумать над фантазиями. Или над другим вариантом - а стоит ли...
За инфу спасибо, буду думать.
Но сейчас я соображаю на счет интеграции и совместной работы с Ликвибэйс (ну или любым другим мигратором).
