让 Phing 的 dbdeploy 任务在增量错误时自动回滚

Question

我正在使用 Phing 的 dbdeploy 任务 到 管理我的数据库架构。只要我的增量文件的查询中没有错误，这就可以正常工作。

但是，如果出现错误，dbdeploy 将仅运行增量文件直至出现错误的查询，然后中止。这让我有些沮丧，因为我必须手动回滚更改日志表中的条目。如果不这样做，dbdeploy 将假定在后续尝试中迁移成功，因此任何重试都不会执行任何操作。

所以问题是，是否有任何方法可以让 dbdeploy 使用事务，或者您是否可以建议任何其他方法来在发生错误时自动回滚 phing？

注意：我对 Phing 不太精通，因此如果这涉及编写自定义任务，则非常感谢任何示例代码或包含更多信息的 url。谢谢

Answer 1

（如果您仍然在那里...）关于数据库转储任务的 phing，请使用数据库的转储实用程序并创建一个 phing 任务。我主要使用 postgres 并在我的 phing build.xml 中包含以下内容：

<target name="db-dump" depends="">
    <php expression="date('Ymd-Hi')" returnProperty="phing.dump.ts"/>
    <exec command="pg_dump -h ${db.host} -U ${db.user} -O ${db.name} | gzip > ${db.dumppath}/${db.name}-${phing.dump.ts}.gz" />
</target>

Answer 2

解决问题的最简单方法是使用 pdoexec 任务，它默认在事务中运行 sql 脚本。当错误发生时，数据库引擎将自动回滚您的更改（即使是更改日志表上的更改 - 数据库将处于以前的状态）

示例：

<pdosqlexec 
    url="pgsql:host=${db.host}
    dbname=${db.name}"
    userid="${db.user}"
    password="${db.pass}"
    src="${build.dbdeploy.deployfile}"
/>

Answer 3

我知道，这是非常古老的线程，但也许它会被其他人充分利用。
您可以使用 try->catch 语句来实现该问题的解决方案。
我的例子：

<trycatch>
    <try>
        <exec
            command="${progs.mysql} -h${db.live.host} -u${db.live.user} -p${db.live.password} ${db.live.name} < ${db.live.output}/${build.dbdeploy.deployfile}"
            dir="${project.basedir}"
            checkreturn="true" />
            <echo>Live  database was upgraded successfully</echo>
    </try>    
    <catch>
            <echo>Errors in upgrading database</echo>
            <exec
            command="${progs.mysql} -h${db.live.host} -u${db.live.user} -p${db.live.password} ${db.live.name} < ${db.live.output}/${build.dbdeploy.undofile}"
            dir="${project.basedir}"
            checkreturn="true" />
    </catch>
    </trycatch>

Answer 4

为什么不编写一系列撤消增量并添加一个在其他任务失败时运行的 phing 任务？

Answer 5

你真的应该看看 capistrano 。
TomTom：您在这里遗漏了一些东西：当然必须在模式更改之前进行备份 - 但是如何处理在您认为一切正常的同时插入的新数据？我并不是说有一个很好的工具可以解决这个问题，但这个问题在现实生活中确实存在。

Answer 6

执行此操作的“正确”方法是在架构更改之前进行备份，然后在出现错误时回滚。

您没有说您使用什么数据库 - 但我会想知道事务中是否支持所有架构更改。大多数大腿末端 SQL 数据库（oracle、db2、sql server）在所有情况下都不会这样做，这是有充分理由的。跨行为模式更改确实非常困难并且非常耗费资源。