Всем доброго дня,

предстоит правка программы миграции базы данных с одно версии на другую.
В частности задача изменить процедуру обновления триггеров.
В принципе понятно что нужно делать но хотелось бы послушать сообщество на тему подводных камней которые могут ждать при обновлении триггеров. Дабы ничего не упустить. Буду признателен за советы и примеры ошибок.

FB2.5.n и FB3.n

Спасибо.

Гаджимурадов Рустам,

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

это миграция внутренних версий. Но в перспективе и между ODS тоже т.к. готовится переход с FB 2.5.9 na FB3.n.

к триггерам никакого но с их обновлением тоже возникали проблемы (не всегда происходило обновление). Проблемма была не в ошибках а в логике обновления. Её и надо изменять.

тут куча внутренних фреймворков которые к 4й версии не адаптированы и ещё даже не начинали тестироваться с ней.
На 4ю версию походу перейдём когда уже будет готова 5я версия.
Тут большой продукт, всё медленно происходит.

правильнее сказать не производилось обновление некоторых триггеров.

а если предполагается миграция данных из одних таблиц в другие я так понимаю допиливать скрипты вручную

вся проблема в том, что в даной программе только частично обновление происходит через скрипты.
Исторически так сложилось (софт уже более 20 лет существует и развивается) что к примеру структура таблиц динамически формируется из из структуры обьектов. Раньше это было нужно для работы с таблицами paradox. Сейчас завершается переход от смешаных данных (paradox + firebird) только на firebird. Но полностью отказаться от старого кода возможности нет т.к. ещё не все клиенты мигрировали на полностью основанную на firebird базу. При инсталляции, по мере перевода модулей основной программы на firebird, осуществляется миграция данных из paradox в firebird. Делает это своя программа миграции, которая также вносит необходимые изменения и в метаданные firebird. Программа сначала накатывает скрипт который удаляет индексы и хранимые процедуры которые могут помешать обновлению (т.к. сушествуют зависимости к примеру). Далее делает резервную копию метаданных индексов и хранимых процедур которые в скрипте удаления не присутствуют и удаляет их тоже, далее меняется структура таблиц если это необходимо, производится миграция данных и делее накатывается скрипт создания индексов и хранимых процедур и далее скрипт из резервной копии созданной в начале (тут есть ошибка в очерёдности, по идее надо сначала накатывать скрипт из резервной копии а потом скрипт обновления, т.к. есть вероятность перезаписи новых хранимок старыми из резервной копии но поскольку до сих пор удавалось все хранимки запихивать в скрипт обновления и в скрипт резервной копии ничего не попадало проблема не поправлена.
До этого момента обновление триггеров производилось только если производилось изменение структуры таблиц сейчас поставлена задача делать это всегда, т.е. удалять сначала все триггеры и потом из создавать заново при каждой инсталляции. Если это делать двумя скриптами то особых проблем нет, но если по той же схеме как с хранимыми процедурами во возникнет проблема очерёдности создания триггеров т.к. она понятно играет важную роль. Соотв возникает вопрос: Есть ли возможность получая исходный код скриптов из базы сделать это в том же порядке как они туда попадали? Было бы удобно сортировать их по ID но у RDB$TRIGGERS такого ID нет. Можно конечно тупо вызвать этот список в неотсортированном виде и по идее этот порядок должен совпадать с тем порядком в котором они вносились но терзают сомнения будет ли это правильным решением.
В данный момент я больше склоняюсь к решению делать всё только через скрипт но было бы интересно прояснить для себя вопрос получения очерёдности создания триггеров.

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

ничто не мешает, поэтому так и планируется сделать.

Dimitry Sibiryakov,

собственно и делаем :) Не студенты конечно, но кто есть.
Топик затеян на случай, вдруг вылезет что то о чём не подумали.
Например упоминание о сравнении баз в IB Expert и генерация скрипта синхронизации натолкнуло на интересные мысли где это можно применить.
Лучше подискутировать чем потом недочёты править.