For anyone else suffering this issue in their Rails app lately since the upgrade I’ve traced it to a deprecation in “acts_as_rateable” and “acts_as_taggable” which both use the value “true” for the dependent parameter instead of one of those listed.

The simple ‘hack’ to fix this is to replace “true” with “:destroy”. You’ll find the offending lines around here:


./vendor/plugins/acts_as_taggable/lib/acts_as_taggable.rb:17: has_many :taggings, :as => :taggable, :dependent => :destroy
./vendor/plugins/acts_as_rateable/lib/acts_as_rateable.rb:12: has_many :ratings, :as => :rateable, :dependent => :destroy


Blogged with Flock

Tags: ruby, rails, plugins

I so wanted to avoid using that horrendous ‘N’ word in any part of my blog but I needed something short for the title.

Anyway – TAW made an interesting post on his first 2 months on Rails and I sympathise with many of his points but for a different reason. Most of the issues he raises aren’t really a problem when you know the Ruby/Rails way of doing it. Which sounds incredibly dismissive so I apologise but it is the way learning any language. Most difficulties are often more to do with trying to program in your ‘native’ Java, Python, PHP using Ruby – it just doesn’t work. Once you get to know Ruby and Rails more and more it eventually becomes clear that Ruby has its own way of doing things – this often means many disheartening setbacks when you realise your amazing whizz-bang class that cooks your dinner can be done in a single line of clever Ruby as opposed to the mountainous 30 line monster you built over a few days.

It’d be worth having a book, blog, website dedicated to just one thing: Showing the Rails/Ruby way of doing common tasks. To save these stumbling blocks for people new too the language and framework. Any volunteers?

Tags: ruby, rails