全部DBFluteプロパティでAdditionalとして手動で付与してあげないといけなーい!というのがありましたが、シノニムでもPKやFK情報を取得できるようにしました。基本、シノニムは他のスキーマのテーブルを見るために自分のスキーマに作るってパターンが多いと思うので。「DBFlute-0.9.3-RC1」をお試し下さい。EmechaのSNAPSHOTボタンでダウンロードできます。Runtimeも「0.9.3-RC1」でMavenリポジトリにあります。【追記】DBFlute-0.9.3は無事リリースされました内部的な実現の仕方ですが、データディクショナリのUSER_SYNONYMSテーブルを利用しています。USER_SYNONYMSUSER_SYNONYMSからシノニム元テーブルがなんなのかを取得し、そのシノニム元テーブルのメタ情報を拾い上げて、シノニムのメタデータにマージしています。FKがちょっとやっかいです。そのシノニムがDBFluteの自動生成対象の場合この場合は、FK先はテーブルではなくシノニムであるべきなので、マージ直前にメタデータ上のFK先をそのシノニムに差し替えます。USER_SYNONYMSが利用できない環境だとこれができないので、その場合は今まで通りとなります。(例外発生したらログ出力して処理を続行します)ちなみにDB2のエリアス(Alias)だと、DB2のJDBCがしっかりとメタデータを戻してくれるのでこのような問題が発生しないようです。FKの部分もどうやらエリアスの分も戻してくれるので、そのままエリアス間で関連されている状態になります。その代わり、テーブルとエリアスを両方自動生成対象にしている場合は、FKが二重になってしまったりするのですが、業務的に両方とも自動生成対象にするってことはないと思うので特に問題はないでしょう。USER_CONS_COLUMNS@DB_LINK_NAMEUSER_TAB_COLUMNSにてカラムとデータタイプが判明する。当然ながらJDBCタイプは不明でありマッピングが必要になる。(DBリンクのシノニムはJDBCからカラム情報すら取得できない)DBFluteで現状でもJDBCタイプが判別できない場合はDB上のタイプの名前による割り切りマッピングを行っているが、それで割り切ってしまうかどうか...USER_CONSTRAINTSの制約のタイプでPKなのかFKなのか判明する。それをもとにUSER_CONS_COLUMNSにてカラム情報を取得する。複合キーの場合は、複数レコードで表現される。順序はPOSITION。【追記】id:hajimeniさんの情報提供により、DBリンクのシノニムもカラム情報とPK情報とUQ情報を取得できるようにしました。DBFlute-0.9.3-RC2です。ありがとうございました!これにより、additionalTableとadditionalPrimaryKeyは利用する必要がなくなります(このために使ってるものは)。FK情報とIndex情報だけは取得できません(制限とします)。ここは今まで変わらずadditionalForeignKeyを使います。RC1を公開しました。再開したディズニーシーにはてなブログをはじめよう!jfluteさんは、はてなブログを使っています。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。