Kiril Mitov blog

The problems with acts_as_paranoid and generally with Soft Delete of records in Rails

I am about to refactor and completely remove acts_as_paranoid from one of the models in our platform. There are certain issues that were piling up in the last few years and it is now already difficult to support it. As I am about to tell this to colleagues tomorrow I thought to first structure the summary in an article and directly send the article to the whole team.

If you are thinking about using acts_as_paranoid and generally soft delete your records then this article could give you a good understanding of what to expect.

Disclaimer: I am not trying to roast acts_as_paranoid here. I think it is a great gem that I’ve used successfully for years and it has helped me save people’s work where they accidentally delete something. It could be exactly what you need. For us it got too entangled and dependent on workarounds with other gems and I am planning to remove it.

acts_as_paranoid VS Globalize – problem 1

We have a model called Material. Material has a title. The title is managed by globalize as we are delivering the content in a number of languages.

class Material < ApplicationRecord
  acts_as_paranoid
  translates :title
end

The problem is that Globalize knows nothing about acts_as_paranoid. You can delete a Material, and it should delete the translations, but when you try to recover the Material then there is an error because of how the translations are implemented and the order in which the translations and the Material are recovered. Which record should be recovered first? Details are at https://github.com/ActsAsParanoid/acts_as_paranoid/issues/166#issuecomment-650974373, but as a quote here

Ok, then I think I see what happens: ActsAsParanoid tries to recover your translations but their validation fails because they are recovered before the main object. When you just call recover this means the records are just not saved and the code proceeds to save the main record. However, when you call recover!, the validation failure leads to the exception you see.

In this case, it seems, the main record needs to be recovered first. I wonder if that should be made the default.

I have work around this and I used it like this for an year

module TranslatableSoftdeletable
  extend ActiveSupport::Concern

  included do

    translation_class.class_eval do
      acts_as_paranoid
    end

    before_recover :restore_translations
  
  end

  def restore_translations
    translations.with_deleted.each do |translation|
      translation.deleted_at = nil
      translation.save(validate: false)
    end
    self.translations.reload
  end

end

acts_as_paranoid VS Globalize – problem 2

Let’s say that you delete a Material. What is the title of this deleted material?

material = Material.find(1)
material.destroy
material.title == ?

Remember that the Material has all of its translations for the title in a table that just got soft deleted. So the correct answer is “nil”. The title of the delete material is nil.

material = Material.find(1)
material.destroy
material.title == nil # is true

You can workaround this with

material.translations.with_deleted.where(locale: I18n.locale).first.title

But this is quite ugly.

acts_as_paranoid VS cancancan

The material could have authors. An author is the connection between the User and the Material. We are using cancancan for the controllers.

In the controller for a specific author we show only the models that are for this author. We have the following rule:

can [:access, :read, :update, :destroy], clazz, authors: { user_id: user.id }

Here the problem is that you can only return non deleted records. If you would like to implement a Trash/Recycle Bin/Bin functionality for the Materials that you can not reuse the rule. The reason is the cancancan can not have can? and cannot? with an sql statement and the “authors: {user_id: user.id}” is an sql statement.

What we could do is to use scopes

# in the ability
can [:access, :read, :update, :destroy], Material, Material.with_authors(user.id)

# In the Material
scope :with_authors, -> (user_ids) {
    joins(:authors).where(authors: {user_id: user_ids})
}

We move the logic for authorization from the ability to the model. I can live with that. It is not that outrageous. But it does not work, because the association with authors will return empty authors for the Material as the materials are also soft deleted.

acts_as_paranoid vs cancancan – case 2

When declaring load_and_authorize in the controller it will not fetch records that are already deleted. So you can not use cancancan to load in the controller a record that is deleted and you must load it yourself.

class MaterialsTrashController < ApplicationController

  before_action only: [:show, :edit, :update, :destroy] do
    @content_picture = Material.only_deleted.find(params[:id])
  end


  load_and_authorize_resource :content_picture, class: "Material", parent: false

end

This was ugly, but as we had one trash controller it was kind of acceptable. But with a second one it got more difficult and deviated from the other controllers logic.

acts_as_paranoid vs ContentPictures

Every Material has many ContentPictures on our platform. There is a ContentPictureRef model. One of the pictures could be the thumbnail. Once you delete a material what is the thumbnail that we can show for this material?

As the content_picture_refs relation as also soft deleted we should change the logic for returning the thumbnail. We change it from

def thumbnail
    thumbnail_ref = self.content_picture_refs.where(content_picture_type:  :thumbnail).first
end

to

def thumbnail
    thumbnail_ref = self.content_picture_refs.with_deleted.where(content_picture_type:  :thumbnail).first
end

I can live with this. Even relation that we have for the deleted record we must call with “with_deleted”. ContentPictures, Authors and other relations all should be changed for us to be able to see the deleted materials in a table that represents the Trash.

acts_as_paranoid vs Active Record Callbacks

There is another issue right at https://github.com/ActsAsParanoid/acts_as_paranoid/issues/168

It took me hours to debug it a few months back. The order of before_destroy should not really matter.

class Episode < ApplicationRecord
   acts_as_paranoid
   before_destroy do 
      puts self.authors.count
   end
   has_many :authors, dependent: :destroy

class Episode < ApplicationRecord
   before_destroy do 
      puts self.authors.count
   end
   acts_as_paranoid 
   has_many :authors, dependent: :destroy

acts_as_paranoid vs belongs_to

By using acts_as_paranoid belongs_to should be:

class Author < ApplicationRecord
   belongs_to :material, with_deleted: true
end

I could also live with this. At a certain stage it was easier to just add with_deleted: true to the belongs_to relations.

acts_as_paranoid vs Shrine

So the Material has a Shrine attachment stored on Amazon S3. What should happen when you delete the Material. Should you delete the file from S3? Of course not. If you delete the file you will not be able to recover the file.

The solution was to modify the Shrine Uploader

class Attacher < Shrine::Attacher

  def activerecord_after_destroy 
    # Just dont call super and keep the file
    # Sine objects at BuildIn3D & FLLCasts are softdeleted we want to 
    # handle the deletion logic in another way.
    true
  end

end

I was living with this for months and did not had many issues.

What Pain and Problem are we addressing?

The current problem that I can not find a workaround for is the MaterialsTrashController that is using CanCanCan. All the solutions would require for this controller to be different than the rest of the controllers and my biggest concern is that this will later result in issues. I would like to have a single place were we check if a User has access to the Material and whether they could read or update it or recover it. If we split the logic of the MaterialsController and the MaterialsTrashController we would end up with a hidden and difficult to maintain duplication.

But was is the real problem that we want to solve?

On our platform we have authors for the instructions and we work close with them. I imagine one particular author that I will call TM (Taekwondon Master). So TM uploads a material and from time to time he incidentally could delete a material. That’s it. When he deletes a Material it should not be deleted, but rather put in a trash. Then when he deletes it from the trash he must confirm with a blood sample. That’s it. I just want to stop TM from losing any Material by accident.

The solution is pretty simple.

In the MaterialsController just show all the materials that do not have a :deleted_at column set.

In the MaterialsTrashController just show only the Materials with :delete_at controller.

I can solve the whole problem with one simple filter that would take me like 1 minute to implement. We don’t need any of the problems above. They simply will not exist.

That’s it. I will start with the Material and I will move through the other models as we are implementing the additional Trash controllers for the other models.