Ectoで個別テーブルによるpolymorphicをしてみる

## はじめに
PhoenixとEcto、とても便利ですよね。ふとEctoのドキュメントを読んでいたらこんなことが書かれていました。`belongs_to`のあたりです。
https://hexdocs.pm/ecto/Ecto.Schema.html#belongs_to/3-polymorphic-associations

どんなことが書かれているのか、疑問に思ったこと、試してみたこと、その所感で構成されています。

## 対訳
まずは訳してみます。章チャプターっぽいのは勝手につけてます。

### ポリモーフィズム

> One common use case for belongs to associations is to handle polymorphism. For example, imagine you have defined a Comment schema and you wish to use it for commenting on both tasks and posts.

`belongs_to`のよくある用途の１つはポリモーフィック関連を扱いたいときでしょう。例えば、`Comment`スキーマを定義したとして、それを`Task`・`Post`の両方のコメント投稿に利用したいとしましょう。

> Some abstractions would force you to define some sort of polymorphic association with two fields in your database:

ある類の抽象化では(※訳注：おそらくRailsを意識している)次の２つのフィールドをDBに定義することでポリモーフィック関連を定義することを強制します：

```
* commentable_type
* commentable_id
```

> The problem with this approach is that it breaks references in the database. You can’t use foreign keys and it is very inefficient, both in terms of query time and storage.
> In Ecto, we have three ways to solve this issue.

この方法の問題点は、データベースレベルでの関連が作れないことです。外部キーも使えませんし、クエリ実効速度の観点からも容量の観点からも非効率です。
Ectoではこれを解決するために３つの方法があります。

### ① 外部キーを並べる

> The simplest is to define multiple fields in the Comment schema, one for each association:

最もシンプルなのは`Comment`スキーマに複数の関連用のフィールドを関連別に用意することです：

```
* task_id
* post_id
```

> Unless you have dozens of columns, this is simpler for the developer, more DB friendly and more efficient in all aspects.

手で数えられる程度のカラム数であればこの方法は開発者に優しく、DBとの親和性が高く、あらゆる面からより効率的です。

### ② 個別テーブル

> Alternatively, because Ecto does not tie a schema to a given table, we can use separate tables for each association. Let’s start over and define a new Comment schema:

EctoはスキーマとDBのテーブルを（直接）結び付けないことから、関連毎に違うテーブルを使用するという方法を取ることができます。ここで新しい`Comment`スキーマを定義することから初めてみましょう：

```elixir
defmodule Comment do
  use Ecto.Schema

  schema "abstract table: comments" do
    # This will be used by associations on each "concrete" table
    field :assoc_id, :integer
  end
end
```

> Notice we have changed the table name to “abstract table: comments”. You can choose whatever name you want, the point here is that this particular table will never exist.

テーブルの名前を`“abstract table: comments”`に変更したことに注目してください。ここには（それがテーブル名として存在しない限り）どんな文字列を入れても構いません。要は架空のテーブルを指定することになります。

> Now in your Post and Task schemas:

`Post` `Task`のスキーマは次のようになります：

```elixir
defmodule Post do
  use Ecto.Schema

  schema "posts" do
    has_many :comments, {"posts_comments", Comment}, foreign_key: :assoc_id
  end
end

defmodule Task do
  use Ecto.Schema

  schema "tasks" do
    has_many :comments, {"tasks_comments", Comment}, foreign_key: :assoc_id
  end
end
```

> Now each association uses its own specific table, “posts_comments” and “tasks_comments”, which must be created on migrations. The advantage of this approach is that we never store unrelated data together, also ensuring we keep database references fast and correct.

これなら各関連はそれぞれ（`"posts_comments"` `"tasks_comments"`という）独自のテーブルを使うことになるので、もちろん個別にマイグレーションされなければなりません。この方法の利点は互いに関係のないデータを一緒にストアしないということと、速くて正確な参照ができるということです。

> When using this technique, the only limitation is that you cannot build comments directly. For example, the command below

この方法を使った場合の制限は、コメントを直接作ることができないということのみです。例えば

```elixir
Repo.insert!(%Comment{})
```

> will attempt to use the abstract table. Instead, one should use

このコードは抽象(存在しない)テーブルを利用しようとします。代わりに、

```elixir
Repo.insert!(build_assoc(post, :comments))
```

> where build_assoc/3 is defined in Ecto. You can also use assoc/2 in both Ecto and in the query syntax to easily retrieve associated comments to a given post or task:

こちらを使うべきでしょう。`build_assoc/3`は`Ecto`に定義されています。`Post`や`Task`に紐付いたコメントを取得するには`Ecto`モジュールか query syntax に存在する `assoc/2` を利用できます：

```elixir
# Fetch all comments associated with the given task
Repo.all(assoc(task, :comments))

#Or all comments in a given table:
Repo.all from(c in {"posts_comments", Comment}), ...)
```

### ③ `many_to_many`を使う
> The third and final option is to use many_to_many/3 to define the relationships between the resources. In this case, the comments table won’t have the foreign key, instead there is a intermediary table responsible for associating the entries:

３つ目の手段は`many_to_many/3`を用いてリソース同士の関連を定義する方法です。この場合`comments`テーブルは外部キーを持たず、新たに中間テーブルが`Post`と`Comment`、`Task`と`Comment`間の関連付けに責任を持ちます：

```elixir
defmodule Comment do
  use Ecto.Schema
  schema "comments" do
    # ...
  end
end

defmodule Post do
  use Ecto.Schema

  schema "posts" do
    many_to_many :comments, Comment, join_through: "posts_comments"
  end
end

defmodule Task do
  use Ecto.Schema

  schema "tasks" do
    many_to_many :comments, Comment, join_through: "tasks_comments"
  end
end
```

> See many_to_many/3 for more information on this particular approach.

詳しくは [`many_to_many/3`](https://hexdocs.pm/ecto/Ecto.Schema.html#many_to_many/3) を参照してください。


（以上）

## 疑問
ポリモーフィック関連って、そもそもどうして必要なのでしょう。例えばこちらの記事を参考にしてみます。
[Railsのポリモーフィック関連とはなんなのか | Qiita](https://qiita.com/itkrt2y/items/32ad1512fce1bf90c20b)

読んでいただくと、まさに上の訳に書いてある内容にあることがアンチパターンだといわれてる！！という状態にあることに気づきます。①はダックタイピングのNG例として挙げられているレベルです。（Phoenixでもそのように使うかはともかく…）
さらに個人的には①は`xxx_id`が`nil`になる可能性があるのも好きじゃないポイントです。NOT NULLできません。その点では①を改善したのが③になると考えています。

個人的に疑問が残ったのは②でした。一体これはどういう実装・動作になるのでしょう。先のリンクでは

> ただ、EmployerMessageとEmployeeMessageが同じインターフェースを持つのならば、この方法では同じコードを繰り返し書くことになるのであまり好ましくありません。
> また、メッセージ送信者モデルが増えれば増えるほどコードの重複も増え、複雑度もそれに応じて高くなることが予想されます。

と書かれていた手法に似ています。DRYじゃないってことですね。
なぜこの方法がドキュメントで紹介されているのでしょうか。

## 作ってみた
ドキュメントも不完全だし自分で実装してみたほうが速い！というわけでサンプルアプリケーションを作ってみました。
＞　[ndac-todoroki/ecto_abstract_table_test](https://github.com/ndac-todoroki/ecto_abstract_table_test)　＜

まぁコード見てもらったほうが速いと思うんであんまり説明することもないですが、実はこの②の方法、比較的Railsのポリモーフィックに近いものであることがわかります。
特徴を整理すると、

- コメント用テーブルはコメント先の数だけ必要
- スキーマは１つ
- 関数のたぐいも一箇所に集められる

ということになります。つまりアプリケーション側での名前とDBでの名前との関連が密ではないので、ロジック部分だけポリモーフィックな感じにすることができる、というわけですね。DBレベルでは完全に独立したテーブルなので速度も`NOT NULL`も犠牲にならないし、（今回のサンプルで言えば）`Blog` や `Blog.Comment` モジュールあたりで[抽象化を完結させれば](https://github.com/ndac-todoroki/ecto_abstract_table_test/blob/master/lib/ecto_abstract_table_test/blog/blog.ex)外側から何に対するコメントであるかを気にする必要もほぼ無いわけです。

> ただ、EmployerMessageとEmployeeMessageが同じインターフェースを持つのならば、この方法では同じコードを繰り返し書くことになるのであまり好ましくありません。
> また、メッセージ送信者モデルが増えれば増えるほどコードの重複も増え、複雑度もそれに応じて高くなることが予想されます。

このあたりも抽象モジュールを用意したことで解決していることがわかります。そのモジュールに共通の動作を書いていくだけで良いことになります。

## 注意点

ただし気にしなくてはいけないことがあります。

#### 1.（種類を問わず）コメントを新しい順に取得、などの用途はJOINが必要
これは当たり前なんですが、`comments`テーブルなるものは存在しないので `Comment |> Repo.all` みたいなことはできません。ちなみにサンプルではそういう実装をしてありますのでエラーが出ます（READMEからコピペ）

```
iex(5)> Blog.list_comments

01:00:05.942 [debug] QUERY ERROR source="abstract table: comments" db=10.5ms queue=0.2ms
SELECT a0."id", a0."assoc_id", a0."inserted_at", a0."updated_at" FROM "abstract table: comments" AS a0 []
** (Postgrex.Error) ERROR 42P01 (undefined_table): relation "abstract table: comments" does not exist
    (ecto) lib/ecto/adapters/sql.ex:431: Ecto.Adapters.SQL.execute_and_cache/7
    (ecto) lib/ecto/repo/queryable.ex:133: Ecto.Repo.Queryable.execute/5
    (ecto) lib/ecto/repo/queryable.ex:37: Ecto.Repo.Queryable.all/4
```

Railsの説明のリンクの方から引用しますが、

> もしポリモーフィックを使わずにやるならば、以下のようにEmployerMessageモデル（employer_messagesテーブル）とEmployeeMessageモデル（employee_messagesテーブル）を作り、thread_idのような両テーブルに共通するカラムを用意してJOINする、などという方法が考えられます。

みたいなことを実装する必要があるでしょう。ただしこれも `Blog.Comment` の中に隠してしまえば表からは特に気にする必要もありません。

#### 2. カラムの追加削除をする場合は工夫したほうが良さげ
例えばたくさん commentable なテーブルができて、それぞれにたいして `hoge_comments` なテーブルを作成していくと、ここのレベルでのコードの管理が大変になります。migrationファイルが増えるとDSLだし読みにくいです。
この場合は、例えば「コメントにトリップを追加する」のであれば１つのマイグレーションファイルですべてのコメント系テーブルをアップデートするようにしたほうが後から読み返した開発者に優しくなります。

あるいはマイグレーションファイルもexsですから、それ用にマクロを作っちゃっても良い…のかもしれませんね。


## おわりに

目的別にDBどんどん分けちゃえばいいじゃん！って話はElixir forumとかででてますね。ポリモーフィズムだけではなく、DDD的なサービスを分割して組み上げる際にもそのドメインに必要な最低限のデータをDBに保存してしまう、同系列のデータベースはPhoenix.PubSubで同期する、関連はシンプルにする、みたいなやり方はElixirがオブジェクトを扱わず高速にDBの読み書きができる恩恵でもあるのかもしれません。

今回はちょっと実験したのでシェアしてみました。何かお気づきの点ありましてもなくてもコメントで指摘していただければと思います。あと仕事もいただければ