Flowdock
Active Record objects don't specify their attributes directly, but rather infer them from the table definition with which they're linked. Adding, removing, and changing attributes and their type is done directly in the database. Any change is instantly reflected in the Active Record objects. The mapping that binds a given Active Record class to a certain database table will happen automatically in most common cases, but can be overwritten for the uncommon ones. See the mapping rules in table_name and the full example in link:files/README.html for more insight. == Creation Active Records accept constructor parameters either in a hash or as a block. The hash method is especially useful when you're receiving the data from somewhere else, like a HTTP request. It works like this: user = User.new(:name => "David", :occupation => "Code Artist") user.name # => "David" You can also use block initialization: user = User.new do |u| u.name = "David" u.occupation = "Code Artist" end And of course you can just create a bare object and specify the attributes after the fact: user = User.new user.name = "David" user.occupation = "Code Artist" == Conditions Conditions can either be specified as a string or an array representing the WHERE-part of an SQL statement. The array form is to be used when the condition input is tainted and requires sanitization. The string form can be used for statements that don't involve tainted data. Examples: User < ActiveRecord::Base def self.authenticate_unsafely(user_name, password) find(:first, :conditions => "user_name = '#{user_name}' AND password = '#{password}'") end def self.authenticate_safely(user_name, password) find(:first, :conditions => [ "user_name = ? AND password = ?", user_name, password ]) end end The <tt>authenticate_unsafely</tt> method inserts the parameters directly into the query and is thus susceptible to SQL-injection attacks if the <tt>user_name</tt> and +password+ parameters come directly from a HTTP request. The <tt>authenticate_safely</tt> method, on the other hand, will sanitize the <tt>user_name</tt> and +password+ before inserting them in the query, which will ensure that an attacker can't escape the query and fake the login (or worse). When using multiple parameters in the conditions, it can easily become hard to read exactly what the fourth or fifth question mark is supposed to represent. In those cases, you can resort to named bind variables instead. That's done by replacing the question marks with symbols and supplying a hash with values for the matching symbol keys: Company.find(:first, [ "id = :id AND name = :name AND division = :division AND created_at > :accounting_date", { :id => 3, :name => "37signals", :division => "First", :accounting_date => '2005-01-01' } ]) == Overwriting default accessors All column values are automatically available through basic accessors on the Active Record object, but some times you want to specialize this behavior. This can be done by either by overwriting the default accessors (using the same name as the attribute) calling read_attribute(attr_name) and write_attribute(attr_name, value) to actually change things. Example: class Song < ActiveRecord::Base # Uses an integer of seconds to hold the length of the song def length=(minutes) write_attribute(:length, minutes * 60) end def length read_attribute(:length) / 60 end end You can alternatively use self[:attribute]=(value) and self[:attribute] instead of write_attribute(:attribute, vaule) and read_attribute(:attribute) as a shorter form. == Accessing attributes before they have been typecasted Sometimes you want to be able to read the raw attribute data without having the column-determined typecast run its course first. That can be done by using the <attribute>_before_type_cast accessors that all attributes have. For example, if your Account model has a balance attribute, you can call account.balance_before_type_cast or account.id_before_type_cast. This is especially useful in validation situations where the user might supply a string for an integer field and you want to display the original string back in an error message. Accessing the attribute normally would typecast the string to 0, which isn't what you want. == Dynamic attribute-based finders Dynamic attribute-based finders are a cleaner way of getting (and/or creating) objects by simple queries without turning to SQL. They work by appending the name of an attribute to <tt>find_by_</tt> or <tt>find_all_by_</tt>, so you get finders like Person.find_by_user_name, Person.find_all_by_last_name, Payment.find_by_transaction_id. So instead of writing <tt>Person.find(:first, ["user_name = ?", user_name])</tt>, you just do <tt>Person.find_by_user_name(user_name)</tt>. And instead of writing <tt>Person.find(:all, ["last_name = ?", last_name])</tt>, you just do <tt>Person.find_all_by_last_name(last_name)</tt>. It's also possible to use multiple attributes in the same find by separating them with "_and_", so you get finders like <tt>Person.find_by_user_name_and_password</tt> or even <tt>Payment.find_by_purchaser_and_state_and_country</tt>. So instead of writing <tt>Person.find(:first, ["user_name = ? AND password = ?", user_name, password])</tt>, you just do <tt>Person.find_by_user_name_and_password(user_name, password)</tt>. It's even possible to use all the additional parameters to find. For example, the full interface for Payment.find_all_by_amount is actually Payment.find_all_by_amount(amount, options). And the full interface to Person.find_by_user_name is actually Person.find_by_user_name(user_name, options). So you could call <tt>Payment.find_all_by_amount(50, :order => "created_on")</tt>. The same dynamic finder style can be used to create the object if it doesn't already exist. This dynamic finder is called with <tt>find_or_create_by_</tt> and will return the object if it already exists and otherwise creates it, then returns it. Example: # No 'Summer' tag exists Tag.find_or_create_by_name("Summer") # equal to Tag.create(:name => "Summer") # Now the 'Summer' tag does exist Tag.find_or_create_by_name("Summer") # equal to Tag.find_by_name("Summer") == Saving arrays, hashes, and other non-mappable objects in text columns Active Record can serialize any object in text columns using YAML. To do so, you must specify this with a call to the class method +serialize+. This makes it possible to store arrays, hashes, and other non-mappable objects without doing any additional work. Example: class User < ActiveRecord::Base serialize :preferences end user = User.create(:preferences) => { "background" => "black", "display" => large }) User.find(user.id).preferences # => { "background" => "black", "display" => large } You can also specify a class option as the second parameter that'll raise an exception if a serialized object is retrieved as a descendent of a class not in the hierarchy. Example: class User < ActiveRecord::Base serialize :preferences, Hash end user = User.create(:preferences => %w( one two three )) User.find(user.id).preferences # raises SerializationTypeMismatch == Single table inheritance Active Record allows inheritance by storing the name of the class in a column that by default is called "type" (can be changed by overwriting <tt>Base.inheritance_column</tt>). This means that an inheritance looking like this: class Company < ActiveRecord::Base; end class Firm < Company; end class Client < Company; end class PriorityClient < Client; end When you do Firm.create(:name => "37signals"), this record will be saved in the companies table with type = "Firm". You can then fetch this row again using Company.find(:first, "name = '37signals'") and it will return a Firm object. If you don't have a type column defined in your table, single-table inheritance won't be triggered. In that case, it'll work just like normal subclasses with no special magic for differentiating between them or reloading the right type with find. Note, all the attributes for all the cases are kept in the same table. Read more: http://www.martinfowler.com/eaaCatalog/singleTableInheritance.html == Connection to multiple databases in different models Connections are usually created through ActiveRecord::Base.establish_connection and retrieved by ActiveRecord::Base.connection. All classes inheriting from ActiveRecord::Base will use this connection. But you can also set a class-specific connection. For example, if Course is a ActiveRecord::Base, but resides in a different database you can just say Course.establish_connection and Course *and all its subclasses* will use this connection instead. This feature is implemented by keeping a connection pool in ActiveRecord::Base that is a Hash indexed by the class. If a connection is requested, the retrieve_connection method will go up the class-hierarchy until a connection is found in the connection pool. == Exceptions * +ActiveRecordError+ -- generic error class and superclass of all other errors raised by Active Record * +AdapterNotSpecified+ -- the configuration hash used in <tt>establish_connection</tt> didn't include a <tt>:adapter</tt> key. * +AdapterNotFound+ -- the <tt>:adapter</tt> key used in <tt>establish_connection</tt> specified an non-existent adapter (or a bad spelling of an existing one). * +AssociationTypeMismatch+ -- the object assigned to the association wasn't of the type specified in the association definition. * +SerializationTypeMismatch+ -- the object serialized wasn't of the class specified as the second parameter. * +ConnectionNotEstablished+ -- no connection has been established. Use <tt>establish_connection</tt> before querying. * +RecordNotFound+ -- no record responded to the find* method. Either the row with the given ID doesn't exist or the row didn't meet the additional restrictions. * +StatementInvalid+ -- the database server rejected the SQL statement. The precise error is added in the message. Either the record with the given ID doesn't exist or the record didn't meet the additional restrictions. * +MultiparameterAssignmentErrors+ -- collection of errors that occurred during a mass assignment using the +attributes=+ method. The +errors+ property of this exception contains an array of +AttributeAssignmentError+ objects that should be inspected to determine which attributes triggered the errors. * +AttributeAssignmentError+ -- an error occurred while doing a mass assignment through the +attributes=+ method. You can inspect the +attribute+ property of the exception object to determine which attribute triggered the error. *Note*: The attributes listed are class-level attributes (accessible from both the class and instance level). So it's possible to assign a logger to the class through Base.logger= which will then be used by all instances in the current object space.

Aliases

  • attributes_with_quotes
  • set_table_name
  • set_primary_key
  • set_inheritance_column
  • set_sequence_name
  • sanitize_sql
  • respond_to?
  • connection=
Show files where this class is defined (12 files)
Register or log in to add new notes.
September 10, 2008
4 thanks

Be careful with overriding dynamic attribute based finders

don’t try something like this:

class Foo < ActiveRecord::Base
  def self.find_by_bar(*args)
    foo = super(*args)
    raise SomeCustomException unless foo
    foo
  end
end

In newer versions of rails, method_missing defines find_by_bar when you first use it. By calling super, you’re triggering method_missing and overwriting your custom definition! It will work the first time then break! Manually write the call to find!

July 22, 2008
1 thank

update_attribute!

I don’t know why, but method update_attribute! is missing. May be it would be useful for somebody:

class ActiveRecord::Base
  def update_attribute!(name, value)
    send(name.to_s + '=', value)
    save!
  end
end
June 2, 2009 - (>= v2.2.1)
1 thank

Do not create an [ ] method

I created a helper method to access some meta data using

def [](name)
  # do stuff
end

This breaks ActiveRecord behaviors. all belongs_to relations were broken

eg.

class Image
  belongs_to :album
end

i = Image.find :first
i.album_id # 1
i.album # nil

Album.find 1 # works

If you experience this behavior, you probably created a method that breaks the default systematics (like I did with the [ ] method)

October 18, 2008
0 thanks

Single Table Inheritance and Fixtures

All entries for fixtures for classes derived from the base class must go into the fixture file of the base class. Also, their type must be set. Example fixture:

company_one:
  name: My Company

firm_one:
  name: A Firm
  type: Firm

priority_client_with_p1:
  name: SuperVIPClient
  type: PriorityClient
  priority: 1
May 15, 2012
0 thanks

STI - Making callbacks trigger in inherited classes

Assuming we have

class ParentClass < ActiveRecord::Base
   attr_accessible :type
end

class ChildClass < ParentClass
   after_save :perform_something
end

Executing

ParentClass.create({:type => "ChildClass"})

will not trigger ChildClass callbacks. What is more, it will return instance of ParentClass instead of ChildClass.

To resolve this issue, you need to define following module

module ActiveRecord
  module CallbacksAwareSti
    extend ActiveSupport::Concern
    module ClassMethods
      def new(*args, &block)
        return super(*args, &block) unless args.first.respond_to?(:with_indifferent_access)
        type = args.first.with_indifferent_access[:type]
        if type.blank? or (type = type.constantize) == self
          super(*args, &block)
        else
          super(*args, &block).becomes(type)
        end
      end
    end
  end
end

and include it in parent class

class ParentClass < ActiveRecord::Base
   include ActiveRecord::CallbacksAwareSti
   attr_accessible :type
end

Inspired by http://stackoverflow.com/questions/4518935/activerecord-problems-using-callbacks-and-sti