liquibase preConditions 的最佳实践答案

【问题标题】：Best practices on liquibase preConditionsliquibase preConditions 的最佳实践
【发布时间】：2021-02-13 18:19:40
【问题描述】：

我正在寻找关于何时在 Liquibase changeSet 中使用 preConditions 的最佳实践。我了解它有助于检查数据库的现有状态然后应用更改的事实。如果我要从一开始就使用 Liquibase 并且所有更改都将通过 Liquibase 完成，changeSet 是否足以检查/验证现有状态？在这种情况下，写preConditions 在我看来更加多余。我还没有找到任何关于这方面的好文档。

在我的用例中，我将使用 Liquibase 进行数据库架构更改 + 在几个表中添加元数据。我看到了一些数据库模式更改查询的示例，例如添加表、列等，其中使用了preConditions。但在正常的插入、更新、删除查询方面看不到太多。为此类数据操作查询编写preConditions 是否也是一种好习惯？这方面有什么好的文档吗？

【问题讨论】：

标签： java database liquibase

【解决方案1】：

是的 - 你应该写前置条件。在每一个变更集上。总是。您的变更集应该是原子的，因此为它们编写前置条件一点也不难。只是需要一点自制力。

否 - changeSet id 不足以检查/验证现有状态。在理想的世界里，一切都非常顺利，没有错误，没有人用他们的脏手弄乱数据库，这可能就足够了。或者有人可以在你的 databaseChangeLog 中间插入一些其他的 changeSet 和理想的流程，仅基于 changeSets 的顺序和身份将被破坏。

但是我们的世界并不理想，所以否，changeSet的ID是不够的。你需要前置条件。

此外，如果您想了解有关如何确定 changeSet 身份的更多信息，请查看此question。

回答关于在执行插入、更新和删除查询之前检查数据的问题的第二部分：

你总是可以使用<sqlCheck>标签。

<changeSet id="foo" author="bar">
    <preConditions onFail="MARK_RAN">
        <sqlCheck expectedResult="0">
            SELECT COUNT(*) FROM user WHERE full_name='John Doe';
        </sqlCheck>
    </preConditions>
    <sql>
       <!-- your custom SQL query here which modifies data somehow -->
    </sql>
</changeSet>

【讨论】：

【解决方案2】：

由于“最佳实践”类型的问题很少有一个正确答案，我将添加自己的答案。

我的公司运行一个单一的应用程序，并且使用 liquibase 进行变更管理已有 5 年多的时间了。我们是一个由 4 名开发人员组成的团队，已经在 100 多台服务器上部署了我们的应用程序。我们从不使用前置条件，而且我不记得曾经遇到过前置条件会有所帮助的 liquibase 问题。另一方面，除了通过 liquibase 之外，我们非常努力地不进行 db 更改，因为我们完全依赖这个假设。

只要确保每个人都在同一个页面上，就可以了。

注意：我在调查先决条件时发现了这个问题，因为我们正在编写另一个应用程序，它将共享单体架构的一部分。因为变更日志将在逻辑上分布在独立发展的多个项目中，我们的假设可能不再成立。如果您计划在多个项目之间共享数据库，请记住这一点。

【讨论】：