Just wasted a full day on this… Suppose you have a User model, with certain Users being children and other Users being parents. With the following code I intended to delete the parent when the child being deleted is the last child of the parent:
class ChildParent < ActiveRecord::Base belongs_to :child, :class_name => "User" belongs_to :parent, :class_name => "User" end class User < ActiveRecord::Base has_many :parents, :through => :child_parents_as_child has_many :child_parents_as_child, :foreign_key => :child_id, :class_name => "ChildParent", :dependent => :destroy has_many :children, :through => :child_parents_as_parent has_many :child_parents_as_parent, :foreign_key => :parent_id, :class_name => "ChildParent", :dependent => :destroy before_destroy :determine_parents_to_be_destroyed after_destroy :destroy_parents private def determine_parents_to_be_destroyed @destroy_parents =  self.parents.each do |p| @destroy_parents << p unless p.children.size > 1 end end def destroy_parents @destroy_parents.each do |p| p.destroy end end end
This didn’t work –
@destroy_parents was never populated. Finally I stumbled on the following sentence, clearly documented in the api for ActiveRecord, yet easily missed: *IMPORTANT:* In order for inheritance to work for the callback queues, you must specify the callbacks before specifying the associations. Otherwise, you might trigger the loading of a child before the parent has registered the callbacks and they won‘t be inherited.
after_destroy declarations above the associations solved the problem.
The Rubyenrails 2009 Conference, held in Amsterdam as previous years, has just finished. What was new, what was hot and what’s in it for the customer?
One of the nice surprises was the increasing number of large(r) companies that are using Ruby on Rails, to name some examples: Tele2, Nedap, Ordina. Adoption of Rails varies from usage in one department to being the strategic platform of choice.
This nicely coincides with the inspiring talk by Jeremy Kemper who observes that both Ruby and Rails are not hypes anymore but are becoming mainstream.
The real-life example omroep.nl (presentation by Bart Zonneveld and Sjoerd Tieleman) illustrates what Ruby on Rails can do for the web development industry. Within 6 months a small team built both the site itself and a custom CMS that interfaces with an existing image library. If anything, this example shows both the maturity of the platform and the rapid development cycles that can be achieved.
Customers usually don’t care much which database is being used, as long as the functionality of the website works as desired. Perhaps this will be different for MongoDB (presentation by Michael Dirolf), a new document-based schema-free database. Letting go of schemas is quite a step for anybody involved in modern relational databases but it opens up a huge potential for flexibility all the way up to the end-user. An administrator wants a new User field for sub-departments? With MongoDB at the back this will be trivial. Sure, such functionality is possible with a relational database as well, but requires quite a bit more work.
Last but not least Jeremy Kemper and Yehuda Katz highlighted the improvements that Rails 3.0 will bring. Many excellent changes are of technical nature and invisible to customers but the speed-up of the framework (up to 10x for collection rendering) and the improved support for encoding and time zones will likely have a noticable effect on the (international) user experience.
What is your take on the advantages Rails 3.0 will bring?