参考
- PostgreSQL のスキーマとは: CREATE SCHEMA
やってみた。まずはデータベース public スキーマで detectVirtualRelations
が発動することを確認する。
まず、環境は k1LoW/tbls を初めて使い始めたいのでサンドボックスとして Docker で PostgreSQL 環境を改めて作った – oki2a24 で準備したものを使用した。
実行したコマンドまとめ。
DB テーブルの準備
tbls 実行コマンド。 先ほど作成したデータベース、テーブルに対して、スーパーユーザー postgres で tbls を実行する。
結果。
外部キーは無しのテーブルだが、 detectVirtualRelations
によって posts, role_user にリレーションが貼られていることを確認できた!
public スキーマではなく、別のスキーマでも自動リレーション検出により貼られるのか?
別DBになるので .tbls.yml も作り直す。
前回と同様テーブルに外部キーは無し、かつ、 detectVirtualRelations
を設定した。
ところが tbls doc
を実行しとたころ、期待とは異なり posts, role_user にリレーションは貼られていなかった。
違いは、 public スキーマではなく、ユーザ名のスキーマに属するテーブルという点のみ。
おわりに
PostgreSQL のデータベースで、 public スキーマではなくそれ以外のスキーマにテーブル等が属しているものを扱う機会があります。
このデータベースは Laravel を通して利用され、テーブル同士のリレーションは Laravel の規約に沿っています。
つまり、 users テーブルがあり、このテーブルにリレーションを作りたい時はそのテーブルに user_id というカラムがあります。
それで、諸般の事情により user_id には外部キーが設定されていません。普通にあることだと思います。
このようなデータベースに対して、 k1LoW/tbls を実行してリレーション付きの状態のデータベースドキュメントを作りたいと思いました。
結果は、、、ダメでした。ドキュメントは生成できたものの、 detectVirtualRelations
自動検知によるリレーションが設定されないのです。
初めて k1LoW/tbls を利用したのがこのデータベースだったため、 detectVirtualRelations
は実は機能しない?という可能性をまず除外できる検証を行う必要がありました。
それで、 public スキーマとそうでないスキーマで detectVirtualRelations
の発動を確認したのが本投稿となります。
疑問が確認でき、とても解決に近づいた感覚があります♪ 以上です。