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
endThe 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
recoverthis means the records are just not saved and the code proceeds to save the main record. However, when you callrecover!, 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
endacts_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 trueYou can workaround this with
material.translations.with_deleted.where(locale: I18n.locale).first.titleBut 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
endThis 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
endto
def thumbnail
thumbnail_ref = self.content_picture_refs.with_deleted.where(content_picture_type: :thumbnail).first
endI 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: :destroyacts_as_paranoid vs belongs_to
By using acts_as_paranoid belongs_to should be:
class Author < ApplicationRecord
belongs_to :material, with_deleted: true
endI 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.
Reply
You must be logged in to post a comment.