powered by simpleCommunicator - 2.0.51     © 2025 Programmizd 02
Форумы / IBExpert [игнор отключен] [закрыт для гостей] / Новый компарер баз
25 сообщений из 60, страница 2 из 3
Новый компарер баз
    #39097749
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ну и плюс у меня там было кое-что для автоматизации, например, разборка зависимостей была автоматической.
Можно было ещё кое-что допилить, чтобы было его намного легче писать, но до этого руки не дошли.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097759
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
budden> Как теперь IBExpert поможет 7-го числа залить в базу TEST
budden> изменения из обоих DEV1 и DEV2? Насколько я понимаю -
budden> никак, только ручная работа.

1. Срванить D1 c TEST, получить скрипт1.
2. Срванить D2 c TEST, получить скрипт2.
3. Накатить скрипт1, скрипт2.
4. Разрулить проблему с несовместимостью
скриптов, если они есть.

В чём проблема, собсно? А если вручную
можно (т.е. каждый из разработчиков знает,
какие именно объекты нужно перенести, а не
"у меня БД правильная, слейте") - ещё проще.

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

Зачем их вообще сливать, тем более мерджерами/VCS,
если скрипты уже готовы? Выполни их и всё или даже
просто объедини в один скрипт.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097803
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам,

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

Т.е., база становится "программой" и у неё есть кнопка "скомпилировать".

ПОэтому, когда два разрабочтика работают, каждый из них клонирует себе репозиторий
(Mercurial) с исходником серверной части, вносит в него сколько угодно изменнеий.

Когда наступает время сливаться, сливаем репозитории а потом пробуем скомпилировать то, что
в итоге получилось.

Также мы сливаем спец.файл, где написаны alter-ы для таблиц. Его, как правило, руками приходится править.

Но исходники хранимок, вьюх, триггеров, сливаются автоматически. Причём эта технология масштабируется
на большое число разработчиков.

Честно сказать, там были нерешённые вопросы. Например, если изменялась сигнатура взаимно рекурсивных
процедур, то это приходилось руками разруливать.

И иногда получалось, что процедура удалялась после того, как была создана, если порядок сборки неправильно описан.
Это и есть трудности Firebird. Но на это у меня были средства контроля, которые сообщали о том, что процедура такая-то
стёрта. Тогда нужно подправить порядок сборки. На самом деле, это можно было автоматизировать, просто руки не успели
дойти.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097827
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
budden> Скрипт "сделать как надо" у меня делал как надо не только то, что
budden> изменил разработчик, а всю базу. Он собирает абсолютно все
budden> вьюхи, триггеры и хранимки.

Не, я, конечно, не против вашего желания нажить себе
геморрой, но другим-то зачем советовать так мучаться?

> Также мы сливаем спец.файл, где написаны alter-ы для таблиц.
> Его, как правило, руками приходится править.

А, так у вас, по сути, сабжа и никакой автоматизации тут нет.

> И иногда получалось, что процедура удалялась после того,
> как была создана, если порядок сборки неправильно описан.
> Это и есть трудности Firebird.

Я не знаю, что у вас там не получилось и почему порядок
неправильный (в этом тоже FB виноват?), но, по сути, ХП
вообще никогда не нужно удалять при изменении - кроме
случаев, когда это самоцель - достаточно занулить её тело,
поработать с зависимостями и скомпилировать её обратно.

FB тут никаким боком, начиная с какой-то версии он даже
позволял работу с ХП, приводящую к невалидности других
ХП (и не только ХП, наверное, не помню). Собсно, что он
не позволяет (не позволял, как щас - ХЗ) - так это всякую
невалидность таблиц. Но тут все СУБД одинаковы, наверное
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097851
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов Рустам, я хранимки и не удалял - именно обнулял тело.

Альтеры таблиц составляют малую часть всех изменений.

Ну в общем, не убедил вас - и ладно. Главное, чтобы меня услышал автор IBExpert, впрочем даже и это не столь
важно.

Я этим способом пользовался около 10 лет на MS SQL и на Firebird и нахожу его единственно правильным.

Скрипты - система контроля версий - скрипты эволюции - сборка серверной части из скриптов "как надо".

Если ещё буду работать с любой СУБД - буду делать только так.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097949
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамЯ голову на отсечение не дам, но уверен, что это бред.
Т.е. IBE может, конечно, заглянуть внутрь зависимостей
для доп. определения чего-то там (прав, ещё чего-то),
но сами зависимости вычисляет по rdb$dependencies,
а не тупым парсингом. Саша как появится, надеюсь,
просветит на сей счёт, расставит точки на i.


Расставляю... RDB$DEPENDENCIES вообще не анализируется. Потому что в скриптах ее нет. А если есть механизм для анализа зависимостей в скрипте, то зачем использовать другой для анализа зависимостей в базе?
...
Рейтинг: 0 / 0
Новый компарер баз
    #39097959
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buddenГлавное, чтобы меня услышал автор IBExpert

Честно говоря, я твою мысль в отношении компарера не понял.
Он делает то, что должен делать, для чего задумывался. Плохо или хорошо - это другой вопрос.
Твоя-то идея в чем заключается?
...
Рейтинг: 0 / 0
Новый компарер баз
    #39098901
Гаджимурадов Рустам
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBExpert> Расставляю... RDB$DEPENDENCIES вообще не анализируется.
IBExpert> Потому что в скриптах ее нет. А если есть механизм для анализа
IBExpert> зависимостей в скрипте, то зачем использовать другой для ...

Я не очень понял, что ты имеешь в виду под "анализом зависимостей
в скрипте" (чего там анализировать? пустышки ХП, триггеры в конце,
сначала таблицы, потом вьюхи т .д.), но я имел в виду редактирование
ХП - никогда не поверю, что для анализа зависимых от неё объектов
ты какие-то там скрипты формируешь и анализируешь.

Компарер-то сам по себе никаких зависимостей не "анализирует", или ты
результирующий скрипт анализируешь для упорядочивания операторов?
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
Новый компарер баз
    #39099077
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гаджимурадов РустамКомпарер-то сам по себе никаких зависимостей не "анализирует", или ты
результирующий скрипт анализируешь для упорядочивания операторов?


Компарер анализирует зависимости, чтобы сгенерировать корректный скрипт обновления.
Так вот он не таблицу зависимостей анализирует, а DDL объектов БД.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39099989
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBExpert, я тебе на почту написал, тема - "ответ на тему с sql.ru"
...
Рейтинг: 0 / 0
Новый компарер баз
    #39100086
sergq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
вставлю свои пять копеек.

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

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

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


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

по всей видимости ругнулся он на поле вьюхи, которая была вытянута из базы по зависимостям. те в принципе не измененная. вот выполнение скрипта на нем и споткнулось. и по этому повторное сравнение и не нашло изменений. тк по сути эта вьюха была выбрана по "глубоким" зависимостям.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39100172
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buddenIBExpert, я тебе на почту написал, тема - "ответ на тему с sql.ru"

Нет ничего, только в спаме про "невидимые бюстгальтеры". Не твое? :)
Пиши здесь, чё стесняться-то?
...
Рейтинг: 0 / 0
Новый компарер баз
    #39100174
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergqтоже столкнулся. изменил одну процедуру. в ней была использована вьюха.

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


Похоже на багу, если только процедура была изменена. Проверю.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39101679
noisy_by
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
С компарером в новой версии все еще есть проблемы

мастер база имеет индексы
Код: sql
1.
2.
CREATE INDEX REQUEST_MATERIALS_IDX2 ON REQUEST_MATERIALS (RQ_ID, WH_ID, M_ID);
CREATE INDEX REQUEST_MATERIALS_RETURN_IDX2 ON REQUEST_MATERIALS_RETURN (RQ_ID, WH_ID, M_ID);



в слайве индексы
Код: sql
1.
2.
CREATE INDEX REQUEST_MATERIALS_IDX2 ON REQUEST_MATERIALS (RQ_ID, WH_ID);
CREATE INDEX REQUEST_MATERIALS_RETURN_IDX2 ON REQUEST_MATERIALS_RETURN (RQ_ID, WH_ID);



после сравнение базы в IBExpert 2015.11.11.1 и выполнение скрипта индексы не изменились
Код: sql
1.
2.
CREATE INDEX REQUEST_MATERIALS_IDX2 ON REQUEST_MATERIALS (RQ_ID, WH_ID);
CREATE INDEX REQUEST_MATERIALS_RETURN_IDX2 ON REQUEST_MATERIALS_RETURN (RQ_ID, WH_ID);



после сравнения IBExpert 2015.7.26.1 все хорошо
Код: sql
1.
2.
CREATE INDEX REQUEST_MATERIALS_IDX2 ON REQUEST_MATERIALS (RQ_ID, WH_ID, M_ID);
CREATE INDEX REQUEST_MATERIALS_RETURN_IDX2 ON REQUEST_MATERIALS_RETURN (RQ_ID, WH_ID, M_ID);
...
Рейтинг: 0 / 0
Новый компарер баз
    #39101698
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
noisy_by,

Проверил, проблем не обнаружил. Индексы пересоздаются и при добавлении поля в индекс, и при удалении поля из него.
Тесткейз можешь сделать? Одна табличка, пара индексов.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39101751
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergqтоже столкнулся. изменил одну процедуру. в ней была использована вьюха.

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


Проверил на простом примере: вьюха + процедура, делающая выборку из вьюхи. При изменении текста процедуры только она альтерится, вьюху эксперт не трогает.

У тебя, вроде, случай сложнее, но без конкретного примера искать вслепую я не буду.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39102122
budden
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBExpert, письмо было на info@ibexpert.com, 10-го в 19-00.

Здесь не стану писать.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39102374
noisy_by
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
еще раз прогнал сравнение IBExpert 2015.11.12.1
получается эксперт увидел различия, но не удаляет индекс перед созданием нового

Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
/*******************************************************************************
The next statement causes the following error:

This operation is not defined for system tables.
unsuccessful metadata update.
Index REQUEST_MATERIALS_IDX2 already exists.
*******************************************************************************/
CREATE INDEX REQUEST_MATERIALS_IDX2 ON REQUEST_MATERIALS (RQ_ID, WH_ID, M_ID);

/*******************************************************************************
The next statement causes the following error:

This operation is not defined for system tables.
unsuccessful metadata update.
Index REQUEST_MATERIALS_RETURN_IDX2 already exists.
*******************************************************************************/
CREATE INDEX REQUEST_MATERIALS_RETURN_IDX2 ON REQUEST_MATERIALS_RETURN (RQ_ID, WH_ID, M_ID);
...
Рейтинг: 0 / 0
Новый компарер баз
    #39102530
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
noisy_byполучается эксперт увидел различия, но не удаляет индекс перед созданием нового


Я проверял - удаляет. Без воспроизводимого примера сложно понять, в чем проблема.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39102735
noisy_by
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Последняя версия 2015.11.13 индексы удалило.
Спасибо.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39103079
sergq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBExpertsergqтоже столкнулся. изменил одну процедуру. в ней была использована вьюха.

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


Проверил на простом примере: вьюха + процедура, делающая выборку из вьюхи. При изменении текста процедуры только она альтерится, вьюху эксперт не трогает.

У тебя, вроде, случай сложнее, но без конкретного примера искать вслепую я не буду.

вроде на 2015.11.13.1 не наблюдается ничего из мною перечисленного
...
Рейтинг: 0 / 0
Новый компарер баз
    #39103135
sergq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
хотя вроде осталось в некоторых случаях если дропается вьюха с триггерами, то почему-то в скрипте сначала дропается вьюха, потом создается триггер, а потом создается сама вьюха. На триггере ругается, что нет old.x.


И такую еще штуку заметил.

в одной из вьюх последняя строка - комментарий через двойное тире. и в конце строки точка с запятой. просто раньше эта срока была частью запроса. вот на этой вьюхе почему-то не ставится терминатор ; и выполнение скрипта на этой строке ругается.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39103342
IBExpert
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
sergqхотя вроде осталось в некоторых случаях если дропается вьюха с триггерами, то почему-то в скрипте сначала дропается вьюха, потом создается триггер, а потом создается сама вьюха. На триггере ругается, что нет old.x.

Триггеры создаются после создания таблиц и вьюх. Не было бы вьюхи - ругалось бы на ее отсутствие, а не на old.x

sergqв одной из вьюх последняя строка - комментарий через двойное тире. и в конце строки точка с запятой. просто раньше эта срока была частью запроса. вот на этой вьюхе почему-то не ставится терминатор ; и выполнение скрипта на этой строке ругается.

Лучше вообще избавиться от такого комментария. В компарере-то я поправил, но попутно выяснилось, что при выполнении такого статемента через isc_dsql_execute_immediate точка с запятой все равно будет вырезана. И тексты представлений в базах будут различаться, что на следующем прогоне снова обнаружит компарер, и т.д.
...
Рейтинг: 0 / 0
Новый компарер баз
    #39103939
sergq
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
IBExpert,

вот маленький пример

2015.11.13.1

если синхронизировать t1 на t2, то сначала будет создан триггер на спецификацию ( в котором удаляется из вьюхи договора)
А потом уже сама вьюха договора.
И естественно облом выполнения скрипта
...
Рейтинг: 0 / 0
Новый компарер баз
    #39103947
Шавлюк Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Есть простая тестовая база
Код: sql
1.
2.
CREATE TABLE BANK (TEST  INTEGER);
GRANT ALL ON BANK TO PUBLIC;


При сравнении ее самой с собой получаю
Код: sql
1.
REVOKE SELECT, INSERT, UPDATE, DELETE, REFERENCES ON BANK FROM PUBLIC;


Скорее всего дело в RDB$USER_PRIVILEGES, но сам туда ручками я не лазил.
В архиве тестовая база (fb 2.5)
https://yadi.sk/d/dLMduU9CkUPHz
...
Рейтинг: 0 / 0
25 сообщений из 60, страница 2 из 3
Форумы / IBExpert [игнор отключен] [закрыт для гостей] / Новый компарер баз
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]