Petro123Максим НИдея интересная, но думаю перебор, по крайней мере пока.
Контроль имён объектов в тулзе - тоже перебор

Как и все остальные фичи данного тулза? :)

Vladimir BaskakovМаксим Нпропущено...


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

Могут быть или есть? Это как на военной кафедре - ==идете Вы по чистому полю, ни кустика, ни кочки, ни чахлой березки. И тут на Вас из за угла - танк==.
Для начала нужно понять, к чему сам этот ЕАВ. От него больше вреда или пользы. Большая база на такой архитектуре будет вероятно архилетать. Код будет устойцивый такой.
Дропнул поле - пакеты слетели, дропнул атрибут - все делает вид что работает. Пока не придет туда, куда. Это ли не счастье!
«Простые вещи должны оставаться простыми, а сложные — стать выполнимыми» - Ларри Уолл.

Хорошо или плохо использовать EAV, это уже совершенно другой вопрос (не менее острый, кстати если интересно то свежие баталии в соседней ветке - http://www.sql.ru/forum/1020938/hranenie-dannyh-s-gibkoy-strukturoy-i-zaprosy-k-nim). Во многих конторах EAV есть, и его очень много (в частности в моей тоже, поэтому говорю далеко не по наслышке). Ну а если он (EAV) уже есть, то можно его код вот так вот организовать, для того чтобы проще с ним справляться.

Petro123а все остальные фичи как то растекаются на кучу говорильни.

Я никак не пойму, как первокласснику на ней работать. Т.к. объять всё и вся - невозможно.
Теория разработки-управления проектом - хромает.


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

Petro123
Есть прецендент : "Я исправил 50 процедур сегодня и 20 завтра для решения Фича_N".

Как на тулзе это выглядит?
1. Исправил сегодня - ИЗМЕНИВ в CREATE TABLE поле INN: char(25) на char(45)

- как ЗАВТРА сделать UPDATE ver2.2 по фиче Фича_N
- по прежнему - "накатить" непонятно)

Примерно так (я это пока не делал, но думаю):




В итоге, в заранее определенном месте (в папке, в файле, в части файла) определяется место для хранения скриптов версии 2.2.
Ну или никто не мешает самому создать этот файл-папку(или сделать это другими средствами), или выделить место (например спец. комментариями) в файле, но потем правилам, которые заданы в конфиге, чтобы потом можно было автоматизировать.
Затем я набрасываю туда альтерящие скрипты(скрипт) для версии. Причем порядок их дальнейшей сборки (очередность выполнения в базе) можно определить абсолютно по разному (может быть даже отдельно для каждого патча), например тупо по дате создания, или по алфавиту, или по какой либо специальной, заранее настроенной и определенной маске (например сначала файлы в именах или самом содержимом, которых есть слово "ALTER TABLE", затем "CREATE OR REPLACE PACKAGE" и т.д.), в зависимости от того как приянто в коллективе.

Например закидываем туда (прямо ручками, например выгружаем из ИДЕ'шки) уже готовый ваш альтер, а потом впоминаем, что есть зависимые уже исправленные пакеты под этот альтер:




Получаем в файлах патча 2.2 новый файлик, в котором собраны все пакеты из модуля "ЗП", изменившиеся с 1-го июня.
Причем еще доступны опции сборки всех объектов воедино (которые так же можно и нужно гибко настроить, т.е. например сначала идут head, а затем body), ну вплоть до того, что на выходе можно получать готовые, оформленные ликвибейсовские чейнджсеты.

А затем закрываем патч:




Примерно так.

Petro123Максим Нно тоже вполне решаемо при необходимости (скрипт отката и все такое).
круто ты.
Замах на решение кучи проблем. А конкретные вещи правки 4000 процедур у тебя не решаются.
- нужны писать 3 варианта самому:
- накат
- откат
- update

А какой именно проблеме сейчас говорится (а то слегка запутался)?

Petro123Т.е. я при разработке поправил скрипт Create
- как получить "альтящиеся" скрипты и "откатные" скрипты по твоей терминологии.
Их автоматом получить не просто.

Алтерящие скрипты могут сделать ИДЕ-шки и тулзы специальные, я обычно делаю альтер руками и закидываю его в версию.

Petro123Максим Н,
теперь ясно.
- ты поправил надцать скриптов с пометками версии и сразу "в паре" тут же пишешь ALER на все эти правки.
Я это и спрашивал.

Да. Либо хранить альтеры таблицы отдельно от самих исходных скриптов таблиц, например в миграционных скриптах, где все до кучи для версии, а потом можно будет "собрать" в один итоговый скрипт таблицы.

Petro123Максим Н,
теперь ясно.
- ты поправил надцать скриптов с пометками версии и сразу "в паре" тут же пишешь ALER на все эти правки.
Я это и спрашивал.

Да. Либо хранить альтеры таблицы отдельно от самих исходных скриптов таблиц, например в миграционных скриптах, где все до кучи для версии, а потом можно будет "собрать" в один итоговый скрипт таблицы.

Petro123Максим Н,
ну теперь можно написать ВИ:
1. Исправил 15 скриптов CREATE с пометкой аннотациями? вер.2.2
2. Создал 15 новых скриптов с ALTER'ами в папке? вер.2.2
?

Да, или просто:

1. Создал 15 новых альтеров с антотациями в патчевой папке, или в одном патчевом-файле

Заем набрал команду для конкретной таблицы и увидел ее исходный DDL и все историю ее изменения по версиям.

Petro123Максим Н,
это уже ближе к Java.
- аннотации или XML конфиг или?
- аннотации свои придуманные вместе с парсером?
- что делать с маппингом на Java этой генерилки?


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

- как уже говорил в 1-м пункте, описанные в конфиге

- насчет маппинга не уверен, как это может выглядеть? Я думал как о чем то специализированном для БД, управление структурой, на выходе можно получать любого вида код и скрипты (как миграционные, так и скрипты наката, заполненеия справочников, тестовые данные, пересоздание объектов, юнит-тесты и т.д.)

Petro123Максим Н,
это уже ближе к Java.
- аннотации или XML конфиг или?
- аннотации свои придуманные вместе с парсером?
- что делать с маппингом на Java этой генерилки?


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

- как уже говорил в 1-м пункте, описанные в конфиге

- насчет маппинга не уверен, как это может выглядеть? Я думал как о чем то специализированном для БД, управление структурой, на выходе можно получать любого вида код и скрипты (как миграционные, так и скрипты наката, заполненеия справочников, тестовые данные, пересоздание объектов, юнит-тесты и т.д.)

Petro123Максим Н,
- попробуй....IMHO может получиться слишком сложный "конфиг в корне"
- не понял...ну да ладно...
- на Java-хибере писал? Ты делаешь упралятор_БД оторванно от Java.
Я придерживаюсь цикла разработки по линейке:
- UPD_БД ---> UPD_Маппинг ---> UPD_БЛ ---> UPD_ГУИ ---> UPD_Доки и обучение.

IMHO
Удачи!


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

Немного доработал тулзовину, если кому интересно заходите в соседнюю ветку, чтобы здесь дальше не оффтопить:
http://www.sql.ru/forum/1005902/tulza-dlya-raboty-s-ishodnikami-bd