前回 の続き。 よくもまあここまで詰まりポイントがボンボン出てくるもんだと自分の無能っぷりに呆れてきたところです。 この無能感を越え、強くなりたい。

activerecord-importの罠

activerecord-importはINSERTのクエリを1SQLにまとめて実行してくれるGem。 「Rails insert 高速化」とかで検索するとこのactiverecord-importの記事がわんさか出てくる。

このGemを使うと、たしかに何発も実行されていたSQLが1つにまとまってくれるが、INSERTして作られたレコードのidを返却してくれない。正確には特定のDBでしか返してくれない。

なんでや、ワイはidが欲しいんや！

users = []
parames.each do |param|
  users << User.new(param)
end

User.import(users) # => failed_instances、num_inserts、idsの3つのメンバを持つStructオブジェクトが返ってくる。しかし何度やってもidsメンバは空配列。

自分はMySQLを使っていたのだが、MySQLでは返してくれない情報のようだった。
「まじかよ〜」という気持ちでコードを読み漁ったところ、Postgresでしか返してくれない情報だということが判明した（多分）。
※ この辺： https://github.com/zdennis/activerecord-import/blob/master/lib/activerecord-import/import.rb#L125-L127

INSERT後に、登録されたレコードを扱う必要があったので諦めざるを得なかった。 結構時間費やしたので辛み。

v2移行

サービスの仕様が大きく変わるタイミングだったので、v2としてレポジトリレベルで切り分けるかどうするかを考える必要があった。

最初に設計というか全体を考えて検討して、レポジトリまで切り分ける必要はないと判断した。 新しいAPIのエンドポイントが増えるだけで、裏の仕組みは変わらなかったのでそうしたほうがスマートだと思った。

しかし、これは間違いだった。というか考慮漏れだった。 v2側の操作によって、v1側のデータまで書き換えられてしまう操作が1つあった。

少なくともDBは切り分けるのが正解だった。ていうか普通分けるだろって感じだ。 v2開発をしているとv2のことしか目に入らなくなってしまうし、当然開発中にはv2用のデータしか用意しない。

あと、システム開発は大抵最初の設計時には気づかない仕様が後から追加されたり変更されたりというのがあるので、もし最初の時点で共存ができたとしても、いつの間にか共存できない仕様になってたということもあると思う。v1との共存をするのならそこを常に意識していないといけない気がするけど、そんなのできるわけがないマンですね。

APIのコードはできていてるし、変更する箇所は参照先DBくらいなのでそこまで大変ではないけど、神経がすり減る作業になりそうだ...。