@DBFlute, Java, Oracle, Synonym 色々と今まで： OracleのシノニムだとPKやFK情報がなくて、 全部DBFluteプロパティでAdditionalとして 手動で付与してあげないといけなーい！ というのがありましたが、シノニムでもPKやFK情報を 取得できるようにしました。 但し、「接続してるスキーマのシノニム」限定ですが、 基本、シノニムは他のスキーマのテーブルを見るために 自分のスキーマに作るってパターンが多いと思うので。 ぜひ、DBFluteユーザでOracleでシノニムを利用されている方は、 「DBFlute-0.9.3-RC1」をお試し下さい。 EmechaのSNAPSHOTボタンでダウンロードできます。 またRuntimeも「0.9.3-RC1」でMavenリポジトリにあります。 【追記】DBFlute-0.9.3は無事リリースされました 内部的な実現の仕方ですが、 データディクショナリのUSER_SYNONYMSテーブルを利用しています。 select * from USER_SYNONYMS USER_SYNONYMSからシノニム元テーブルがなんなのかを取得し、 そのシノニム元テーブルのメタ情報を拾い上げて、シノニムの メタデータにマージしています。 FKがちょっとやっかいです。 o FK先テーブルにもシノニムがあった場合 o そのシノニムがDBFluteの自動生成対象の場合 この場合は、FK先はテーブルではなくシノニムであるべきなので、 マージ直前にメタデータ上のFK先をそのシノニムに差し替えます。 USER_SYNONYMSが利用できない環境だとこれができないので、 その場合は今まで通りとなります。 （例外発生したらログ出力して処理を続行します）
ちなみにDB2のエリアス(Alias)だと、DB2のJDBCがしっかりと メタデータを戻してくれるのでこのような問題が発生しないようです。 FKの部分もどうやらエリアスの分も戻してくれるので、 そのままエリアス間で関連されている状態になります。 その代わり、テーブルとエリアスを両方自動生成対象にしている場合は、 FKが二重になってしまったりするのですが、業務的に両方とも 自動生成対象にするってことはないと思うので特に問題はないでしょう。 (二重になっても関連するテーブル・エリアス両方に対して結合処理が できるだけなので使えないわけではないです)
【追記】 DBリンク対応への道のりのための備忘録： (情報提供ありがとうございます！) カラム情報 select * from USER_TAB_COLUMNS@DB_LINK_NAME 制約一覧 select * from USER_CONSTRAINTS@DB_LINK_NAME 制約の内容 select * from USER_CONS_COLUMNS@DB_LINK_NAME USER_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を使います。
