Associations aren't :dependent => true anymore

Up until the 1.1 release, the way to automatically destroy has_many associations when the owner was itself destroyed was to either use the :dependent or :exclusively_dependent option when declaring the has_many.

class Account < ActiveRecord::Base
  has_many :members, :dependent => true


class Brand < ActiveRecord::Base
  has_many :products, :exclusively_dependent => true

The :dependent option instantiated all the associated objects and called destroy on each one. Destroy in turn triggers the callbacks defined on that associated model, such as those declared with before_destroy and after_destroy.

The :exclusively_dependent option, on the other hand, did not instantiate all the associated objects. Rather, it just generated a single SQL statement which deleted the associated records without first creating objects for each one. This buys you efficiency when you have no need for the flexibility of triggering model callbacks.

Since 1.1, the API for garbage collecting associated records has been consolidated into the :dependent option. Rather than saying :dependent => true, you now pass one of several symbols to the :dependent option which describes how the association is dependent on the owner.

Declaring the has many as :dependent => :destroy is the same as what used to be declared as :dependent => true. When the owner is destroyed, all the associated records are instantiated and destroyed.

class Account < ActiveRecord::Base
  # Deprecated
  # has_many :members, :dependent => true
  # In favor of
  has_many :members, :dependent => :destroy

The new way to achieve the now deprecated :exclusively_dependent configuration is to use :dependent => :delete_all rather than :dependent => :destroy.

class Brand < ActiveRecord::Base
  # Deprecated
  # has_many :products, :exclusively_dependent => true

  # In favor of
  has_many :products, :dependent => :delete_all

The :destroy and :delete_all option symbols are so named because they correspond with the behavior achieved by calling destroy versus delete on a model object. One triggers callbacks, the other just generates the delete SQL statement.

As an aside, another valid option is :dependent => :nullify which is similar to :dependent => :delete_all except rather than deleting the associated records, it just sets their foreign keys to NULL. This effectively removes the association, without removing the associated records from the database table.

As always, the semantics of :dependent => :destroy and :dependent => :delete_all are mutually exclusive, which this new API makes a bit more apparent.

It should be noted that declaring dependencies is not required when setting up has many associations. It is simply an option for when you desire such functionality.

Keep in mind that for now :dependent => true and :exclusively_dependent => true will still be supported, but they have been marked as deprecated and could be taken out in the future.

New in Rails: Module#alias_method_chain



  module Layout #:nodoc:
    def self.included(base)
      base.class_eval do
        alias_method :render_with_no_layout, :render
        alias_method :render, :render_with_a_layout

  1. … etc



alias_method_chain :render, :layout


Finding programmers and designers for Rails projects

The Signal vs Noise Job Board is a new alternative for finding good programmers and designers to work on Rails projects (among other things). It puts your job pitch in front of the tens of thousands of people reading the Signal vs Noise weblog. It comes at a price of $250 for a posting of 500 words visible for 30 days.

CNET, Fleck, and are all using it to advertise developers with Ruby and Rails experience. If you’re just looking for programming positions, you can subscribe to the RSS for the programming section.

As you might have noticed from the URLs, this job site is using the new Simply Restful plugin. Our playground for RESTful living on Rails.

Use params, not @params

I still frequently see people in the #rubyonrails channel using @params in their code. For a while now @params has been deprecated in favor of simply params. For those who just skim these blog posts:

Use params, not @params

Why? When you use the params method, it allows for the implementation details of the parameter hash to be changed without breaking existing code. If the implementation of params changed you wouldn’t have to change your code at all because the single point of access for the parameters would just remain the params method. So, the details of what is happening behind the scenes don’t matter. If, though, you use the @params instance variable directly, you’ve broken encapsulation and consequently the ability for the implementation to be easily modified. Methods can be refactored, but instance variables can’t. Today the params method just wraps the @params instance variable, so still using @params works, but that’s not guaranteed to always remain the case.

Same goes for request, response, session, headers, template, cookies and flash.

Basically, a good rule of thumb here is don’t use an instance variable in your controller or view unless you created that instance variable.

Even the old @content_for_layout in the layout is deprecated in favor of just using yield in its place. Also content_for('some_fragment') is now accessed with yield :some_fragment rather than @content_for_some_fragment.

EastMedia jumps into the Rails training arena





habtm vs has_many :through

Of late the ActiveRecord association code has been getting a lot of love. One of the high profile additions are polymorphic associations which turned into one of the big features of the 1.1 release. Amongst all the commotion, some may not have noticed that there is an enhanced way to do many to many associations other than with has_and_belongs_to_many.

For some time people have been skipping out on has_and_belongs_to_many in favor of setting up two has_many associations so that they get the benefits of a full join model and what that brings with it. With 1.1’s new :through association option, a two way has_many just got even sweeter. So if there are two ways to do a many to many relationship, what are the differences, and which approach should you take?

Josh Susser has been digging deep into the association code lately and has emerged from the thicket with a point by point comparison of habtm and has_many :through, a dance-off if you will, between the two approaches. This would be a good time to add him to your RSS reader if you haven’t already.

Jobster looking for lots of Rails developers


One of the cool things we have done at jobster
would spin up 4 significant projects.

So far Rails has indeed proven to be a great fit.

A team of three engineers tasked with prototyping a compelling consumer
that all our new consumer features will be built on.


Fluxiom has launched




We await a bevy of great extractions Thomas ;)