Блог

Я подготовил два разных решения для одного вопроса. Под решением я подразумеваю триггеры базы данных, которые вызывают процедуры базы данных. Я хочу, чтобы пользователь/клиент мог выбрать решение, которое он хочет использовать, потому что оба решения имеют преимущества и недостатки. Я также хочу, чтобы пользователь мог изменить решение. Эти два решения являются взаимоисключающими, другими словами, пользователь может использовать только одно решение одновременно.

У меня есть три файла списка изменений:

1. master.xml — он содержит схему базы данных
2. soultion1.xml — он содержит решение 1 (триггеры, процедуры и таблицы)
3. soultion2.xml — он содержит решение 2 (другие триггеры, другие процедуры и другие таблицы)

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

Давайте предположим, что пользователь сначала выберет решение 1, затем он переключится на решение 2, а затем снова переключится на решение 1.

Я никогда не использовал команды тегов и отката, но я читал об этом в документации и у меня есть следующая идея. Пользователь сначала выполняет команду обновления на master.xml. После этого пользователь должен создать тег. Следующий пользователь выполняет команду обновления на soultion1.xml. Чтобы изменить решение, пользователь должен выполнить откат к своему тегу, а затем выполнить команду обновления на soultion2.xml. Если пользователь хочет снова перейти на решение 1, то он должен сначала откатиться к тегу и снова выполнить обновление на soultion1.xml.

Я надеюсь, что моя идея будет работать должным образом, но я ее не тестировал, так что вполне возможно, что она не сработает. К сожалению, у этого решения есть один большой недостаток: пользователь должен помнить о создании тега. Если пользователь забудет создать тег, у него будут проблемы. Пользователю придется подсчитать наборы изменений и использовать команду rollbackCount. Кроме того, триггеры создаются в теге sql в solutions1.xml и solutions2.xml файлы. Я боюсь, что откат не работает должным образом с тегом sql.

Есть ли какое-нибудь лучшее решение?