6

Phingのdbdeployタスクを使用してデータベーススキーマを管理しています。デルタファイルのクエリにエラーがない限り、これは正常に機能しています。

ただし、エラーが発生した場合、dbdeployはエラーのあるクエリまでデルタファイルを実行してから中止します。次に、変更ログテーブルのエントリを手動でロールバックする必要があるため、これはフラストレーションを引き起こします。そうしないと、dbdeployはその後の試行で移行が成功したと見なすため、再試行しても何も起こりません。

したがって、問題は、dbdeploy使用トランザクションを取得する方法はありますか、またはエラーが発生したときにphingを自動的にロールバックする他の方法を提案できますか？

注：私はPhingにそれほど精通していないため、カスタムタスクの作成が含まれる場合は、サンプルコードまたは詳細情報を含むURLを高く評価します。ありがとう

4

6 に答える 6

3

（まだそこにいる場合は...）dbダンプタスクのphingに関しては、dbのダンプユーティリティを使用してphingタスクを作成します。私は主にpostgresを使用しており、これはphingbuild.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>
于 2011-04-07T20:02:44.127 に答える
3

問題を解決する最も簡単な方法は、デフォルトでトランザクションでsqlスクリプトを実行するpdoexecタスクを使用することです。エラーが発生すると、データベースエンジンは変更を自動的にロールバックします（変更ログテーブルにあるものでも-データベースは以前の状態になります）

例：

<pdosqlexec 
    url="pgsql:host=${db.host}
    dbname=${db.name}"
    userid="${db.user}"
    password="${db.pass}"
    src="${build.dbdeploy.deployfile}"
/>
于 2011-12-30T22:35:32.903 に答える
3

これは非常に古いスレッドですが、他の誰かのために完全に使用される可能性があります。try-> catchステートメントを使用して、そのソリューションを実装できます。私の例：

<trycatch>
    <try>
        <exec
            command="${progs.mysql} -h${db.live.host} -u${db.live.user} -p${db.live.password} ${db.live.name} &lt; ${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} &lt; ${db.live.output}/${build.dbdeploy.undofile}"
            dir="${project.basedir}"
            checkreturn="true" />
    </catch>
    </trycatch>
于 2012-05-18T14:50:06.497 に答える
1

一連の元に戻るデルタを作成し、他のタスクの失敗時に実行されるphingタスクを追加してみませんか？

于 2010-03-16T16:51:13.430 に答える
1

あなたは本当にcapistranoを見てみるべきです。TomTom：ここに何かが欠けています：もちろんスキーマ変更前のバックアップを作成する必要があります-しかし、すべてが大丈夫だと思っている間に挿入された新しいデータをどうするか？この問題に適したツールがあるとは言いませんが、問題は現実に存在します。

于 2010-06-28T22:03:08.160 に答える
-1

これを行う「適切な」方法は、スキーマを変更する前にバックアップし、エラーが発生した場合にロールバックすることです。

使用するデータベースはわかりませんが、すべてのスキーマ変更がトランザクションでサポートされるかどうか疑問に思います。Mos thigh end SQLデータベース（oracle、db2、sql server）は、本当に正当な理由で、すべての場合にそれを行うわけではありません。Transacitonalスキーマの変更は、非常に困難であり、リソースを大量に消費します。

于 2010-03-16T11:33:15.647 に答える