eclipse-link.ddl-generation と deby のスキーマについて

<< 戻る   トップ >>

persistence.xml の "eclipselink.ddl-generation" オプションについて、m最善の資料は他ならぬ eclipse-link のドキュメントなのであって Java Persistence API (JPA) Extensions Reference for EclipseLink の 5. Persisitence Property Extension Reference に ddl-generationの説明がある。

DDL とは Data Definition Language であって、SQL はその一種で、現時点では事実上 DDL = SQL という理解でいいだろう。"eclipselink.ddl-generation" は EclipseLink が配備時に、データベースの表や制限などのスキーマにどのように SQL を使うかを規定するのだそうだ。

create-tables
EclipseLink は各表に対して "CREATE TABLE" SQL を実行しようとする。既存の表の場合は、使用しているデータベースと JDBC ドライバの組み合わせの仕様にしたがって動作する。多くの場合は例外がスローされて表は作られない。そして既存の表が使われる。EclipseLink は次のステートメントを処理する。
create-or-extend-tables
EclipseLink は表を作成しようとする。既存の場合は、不足しているカラムを足す。
drop-and-create-tables
EclipseLinkはすべての表を消去し、すべてのテーブルを生成する。うまく処理できなかった場合、使用しているデータベースと JDBC ドライバの組み合わせの仕様にしたがって動作し、次のステートメントを処理する。この値は開発中にスキーマが頻繁に変更され、既存のデータを消去する必要がある時に有効である。
注意: drop-and-create を使用すデフォルトのユーザースキーマはAPPというスキーマです。(これは接続時にユーザ名が与えられなかったときに使われます。) ると、既存の表のデータがすべて消去される。してがって、データベースに重要なデータが含まれる本番では用いてはならない。スキーマが大規模に変更された場合、古い制約が古い表を削除することを妨げるかもしれない。この場合、他の手段で古いスキーマを消去する必要がある。1
none
【デフォルト】SQL (DDL) は生成されず、したがってスキーマも生成されない。

今回のように、あらかじめ作成した表がある場合は省略するか、none を指定すべきだったのだろう。

ただし、使用を予定していたスキーマ APP ではなく、NANBAN が生成されていたという結果を検討すると、APP の表を参照しなかった可能性が大きい。そもそも、JPA または Glassfish のどの設定からスキーマ NANBAN が生じたのだろうか。

derby のスキーマ

Glassfish + derby で EclipseLink.ddl-generation を crate-tables で動作させたら、想定していた APP スキーマではなく NANBAN スキーマに表が生成されていた件であるが、Glassfish でも JPA の仕様でもなく、derby の仕様であることが分かった。スキーマには複数の表や索引など(のディクショナリ)が属し、スキーマの名前はユーザ名が仕様される。ユーザ名が与えられなかったときに APP スキーマを使う。

ようするに、derby のスキーマという考え方を理解せずに作業をすすめようとしたのが間違いであったわけである。

...

さて、上記の記事を書いたのが実は9月5日(木)のことであったりもする。停電で museo-anonimo が停止した日で、アップするのを忘れて今日に至るとともに、それ以来 Sesto 計画に進展もないのであった。ということは、次は @ManyToMany の関係のある二つの表にデータを追加する場合にどうするかが相変わらず課題なのである。


作成: 2013-09-17 16:33:37.0更新: 2013-09-17 16:33:37.0
http://museo-anonimo.jp/nanban/?id=1231,http://museo-anonimo.jp/nanban/tr/1231