On acts_as_paranoid continued
Posted by Richard White Mon, 20 Feb 2006 15:46:00 GMT
A few days ago I mentioned some of my struggles with the acts_as_paranoid Rails plugin. I also mentioned that I solved my problem with making an association to a paranoid model ignore the delete_at field. Unfortunately my fix was not properly tested and does not actually work. When I redefined the def task method I broke def task=.
My workaround to this was a simple, but very ugly, hack. I removed def task and replaced it with the following method.
def task_wrapper
if self.task.nil?
self.task= Task.find_with_deleted(task_id) if task_id != 0
end
self.task
end
Which is basically prefetching that association using the find_with_deleted method given to you by acts_as_paranoid. I would call this method any time before I need to call object.task. See, told you it was messy.
I would have spent more time coming up with a better solution but I soon realized what I was doing had a very funny odor to it. That’s right ye olde dreaded CodeSmell. I remodeled the whole association to better reflect what I was trying to accomplish and now do not use acts_as_paranoid at all (well at least in this case).
Just wanted to followup lest anyone actually think I got it right the first time.
Could you provide a little detail as to how you remodeled things to no longer require acts_as_paranoid?
I’ve always felt like you should really never delete anything just for auditing purposes, so acts_as_paranoid is very interesting to me. Did you end up deleting things? Or just keying them somehow so that they wouldn’t get displayed in the end?
Mat: Basically I releazed that what I was doing when I deleted an item should actually have been modeled as marking it as done (my item was a task). So I basically just changed it into being a boolean value of whether something was done and then using that in my :belongs_to. I still plan to use acts_as_paranoid for the auditing purposes like reporting which is all done via views which can either ignore or check for the deleted status easier than a :belongs_to association can.