詰まったことリスト2

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

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 くらいなのでそこまで大変ではないけど、神経がすり減る作業になりそうだ…。