4

私はPlayで働いています！1.2.4そして私は奇妙な問題に遭遇しました。

構成でjpa.ddlをcreate-dropに設定したかどうかを知る限り、テーブルを削除して再構築し、アプリケーションを再起動する必要があります。

jpa.ddl=create-drop

変更されたモデルに関連付けられたテーブルのみをドロップして作成すると考えるのは正しいですか？モデルを変更しても問題が発生しますが、テーブルが削除されません。テーブルを手動で削除しようとしましたが、それが原因で許可されませんCannot delete or update a parent row: a foreign key constraint fails。私はこの問題を理解しており、それを修正するために、テーブル全体を手動で削除してアプリケーションを再起動し、テーブルを最初から作成することができました。

私の質問は、これがPlayの問題なのかということです。それがそのテーブルを更新しない理由です。もしそうなら、手動でテーブルを削除するのではなく、構成ファイルを介してそれを回避する方法はありますか？

ありがとう。

編集

詳細については、これが問題であり、まったく異なる可能性があると想定していますが、ログに表示される内容は次のとおりです。

Unsuccessful: create table Product
Table 'Product' already exists

また、この負荷で変化が発生していることに気づきました。私は以前そのような関係を持っていました

Product *-* Image

これは、ProductテーブルとImageテーブルの間のManyToMany関係です。Imageテーブルは存在せず、関係はなくなります。ただし、Imageテーブルは削除されていないように見えますが、Product1は削除して再構築しようとしています。これにより、外部キー制約の問題が発生している可能性があります。モデルがもう存在しない場合、Playはそのテーブルを削除しないのはなぜですか？

4

2 に答える 2

0

開発モードでプレイを実行していますか? しかし、jpa.ddl=update を使用しないのはなぜですか?

于 2012-09-10T04:08:30.523 に答える
0

jpa による自動スキーマ変更は、実際には最善の方法ではありません。Play は、何が変更されたかを示すため、より信頼性の高い進化メカニズムを提供します。

あなたが与えた例では、Image のようなモデル クラスを削除すると、JPA は Image クラスについて何も知らないので、Image テーブルと Product_Image リレーションショップ テーブルは削除されません。したがって、Product テーブルを削除することはできません。JPA には、モデルを変更する前のデータベースが何であったかについての知識がありません。

Evolutions ファイルを手動で作成するため、Evolutions を最初に使用するのは少し面倒ですが、このメカニズムを使用すると、データベース構造はまさにあなたが望むものになります。

于 2012-09-10T05:36:19.050 に答える