論理削除gemをacts_as_paranoidからkakurenbo-putiに乗り換えようとした、そして諦めた

世間では論理削除そのものの是非を問うている昨今ですが
rails4にしたらacts_as_paranoidが上手くいかなくなったのでkakurenbo-putiに乗り換えましたようとして諦めました。
本文書は大体エッセイですｗ

kakurenbo-putiについては http://alfa.hatenablog.jp/entry/2015/02/02/233552 も御覧ください

何が辛かったか

• 一言で言ってしまうと 設計思想の違い
  • acts_as_paranoid(paranoid)は利用者に論理削除を意識させないように設計されています
    • 削除のメソッドは既存のAR#destroyメソッドですし論理削除されたオブジェクトはAR#findなどではヒットしないようになってます
  • 対してkakurenbo-putiは利用者に強く物理削除とは異なることを意識させる設計となっています
    • AR#findなどで論理削除したオブジェクトがヒットするようになります、除外したい場合は用意されたスコープ(without_soft_destroyed)を使うことになりこれはacts_as_paranoidの場合と逆です
    • これは上記ブログでも作者の方が言ってるとおりです

kakurenbo(acts_as_paranoid系のgem)はrailsの削除機能を論理削除に置き換えることを目的に作られたgemですが、kakurenbo-putiはrailsに論理削除機能を追加する目的で作られたgemです。

kakurenbo-putiはダメなのか

• そうではないです

  • 既存のそれなりの大きさのプロジェクトに対しての置換えは正直オススメできません

    • 上記の通りスコープがparanoidと逆になるため、コードの大幅な置換えが生じます
      • 特にRailsの場合はfindとかだけではなく関連を使ってhoge.fugeのように関連モデルを呼び出すことが多々あると思われます、こういった書き方とkakurenbo-putiは相性が良くないように思えました
      • paranoidの罪なところは利用者に意識させないところで、書き方によっては物理削除されていないといけないテストが論理削除で通ってしまっていたなんてこともありそうです
    • 漏れ無くミスなく変更する自信がなくて考えてるうちに心が折れましたｗ

  • 新規プロジェクト/小さなプロジェクトならアリです

    • おすすめできないのは変更が必要な箇所が把握できないほど多いプロジェクトです
    • 論理削除の箇所を把握しながら進められるのであれば採用しても良いと思います
    • 少なくともacts_as_paranoidのような既存の機能の置き換え型のgemよりは将来性があるかと思います
      • ※論理削除自体の是非は一旦置いときますｗ

kakurenbo-putiを使わない場合どうするのか

• 削除フラグではなく 削除テーブル を使うのが良いのではないでしょうか
  • 別に新しい技術でもなんでもないのです
  • 論理削除したいタイミングで元のテーブルから別テーブルにコピーするやつです
  • テーブル構成は複雑になりますが、SQLなどはシンプルになるので変なミスが少なくなるんじゃないでしょうか
  • 論理削除相当のメソッドや復活の呪文(メソッド)は提供されてないと思うので自前で用意しないといけないってのはありますが、これが一番ラクな気がします
  • http://blog.webcreativepark.net/2008/05/26-103152.html に少し記述があるのを見つけました、たぶん探せば沢山情報出てくると思います