Active Record objects doesn’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 files/README.html for more insight.
Active Records accepts 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 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 doesn’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 authenticate_unsafely method inserts the parameters directly into the query and is thus susceptible to SQL-injection attacks if the user_name and password parameters come directly from a HTTP request. The authenticate_safely method, on the other hand, will sanitize the user_name 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' } ])
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.
Some times you want to be able to read the raw attribute data without having the column-determined type cast 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 type cast the string to 0, which isn’t what you want.
Dynamic attribute-based finders are a cleaner way of getting objects by simple queries without turning to SQL. They work by appending the name of an attribute to find_by_ or find_all_by_, 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 Person.find(:first, ["user_name = ?", user_name]), you just do Person.find_by_user_name(user_name). And instead of writing Person.find(:all, ["last_name = ?", last_name]), you just do Person.find_all_by_last_name(last_name).
It’s also possible to use multiple attributes in the same find by separating them with "and", so you get finders like Person.find_by_user_name_and_password or even Payment.find_by_purchaser_and_state_and_country. So instead of writing Person.find(:first, ["user_name = ? AND password = ?", user_name, password]), you just do Person.find_by_user_name_and_password(user_name, password).
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 Payment.find_all_by_amount(50, :order => "created_on").
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-mappeable 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 an 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
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 Base.inheritance_column). 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: www.martinfowler.com/eaaCatalog/singleTableInheritance.html
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.
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.
set_table_name | -> | table_name= |
set_primary_key | -> | primary_key= |
set_inheritance_column | -> | inheritance_column= |
sanitize_sql | -> | sanitize_conditions |
respond_to? | -> | respond_to_without_attributes? |
For checking respond_to? without searching the attributes (which is faster). |
If this macro is used, only those attributed named in it will be accessible for mass-assignment, such as new(attributes) and attributes=(attributes). This is the more conservative choice for mass-assignment protection. If you’d rather start from an all-open default and restrict attributes as needed, have a look at attr_protected.
Attributes named in this macro are protected from mass-assignment, such as new(attributes) and attributes=(attributes). Their assignment will simply be ignored. Instead, you can use the direct writer methods to do assignment. This is meant to protect sensitive attributes to be overwritten by URL/form hackers. Example:
class Customer < ActiveRecord::Base attr_protected :credit_rating end customer = Customer.new("name" => David, "credit_rating" => "Excellent") customer.credit_rating # => nil customer.attributes = { "description" => "Jolly fellow", "credit_rating" => "Superb" } customer.credit_rating # => nil customer.credit_rating = "Average" customer.credit_rating # => "Average"
Log and benchmark multiple statements in a single block. Usage (hides all the SQL calls for the individual actions and calculates total runtime for them all):
Project.benchmark("Creating project") do project = Project.create("name" => "stuff") project.create_manager("name" => "David") project.milestones << Milestone.find(:all) end
Returns a hash of all the methods added to query each of the columns in the table with the name of the method as the key and true as the value. This makes it possible to do O(1) lookups in respond_to? to check if a given method for attribute is available.
Returns the connection currently associated with the class. This can also be used to "borrow" the connection to do database work unrelated to any of the specific Active Records.
Returns an array of columns objects where the primary id, all columns ending in "_id" or "_count", and columns used for single table inheritance has been removed.
Returns the number of records that meets the conditions. Zero is returned if no records match. Example:
Product.count "sales > 1"
Returns the result of an SQL statement that should only include a COUNT(*) in the SELECT part.
Product.count "SELECT COUNT(*) FROM sales s, customers c WHERE s.customer_id = c.id"
Creates an object, instantly saves it as a record (if the validation permits it), and returns it. If the save fail under validations, the unsaved object is still returned.
Deletes the record with the given id without instantiating an object first. If an array of ids is provided, all of them are deleted.
Deletes all the records that matches the condition without instantiating the objects first (and hence not calling the destroy method). Example:
Post.destroy_all "person_id = 5 AND (category = 'Something' OR category = 'Else')"
Destroys the record with the given id by instantiating the object and calling destroy (all the callbacks are the triggered). If an array of ids is provided, all of them are destroyed.
Destroys the objects for all the records that matches the condition by instantiating each object and calling the destroy method. Example:
Person.destroy_all "last_login < '2004-04-04'"
Establishes the connection to the database. Accepts a hash as input where the :adapter key must be specified with the name of a database adapter (in lower-case) example for regular databases (MySQL, Postgresql, etc):
ActiveRecord::Base.establish_connection( :adapter => "mysql", :host => "localhost", :username => "myuser", :password => "mypass", :database => "somedatabase" )
Example for SQLite database:
ActiveRecord::Base.establish_connection( :adapter => "sqlite", :dbfile => "path/to/dbfile" )
Also accepts keys as strings (for parsing from yaml for example):
ActiveRecord::Base.establish_connection( "adapter" => "sqlite", "dbfile" => "path/to/dbfile" )
The exceptions AdapterNotSpecified, AdapterNotFound and ArgumentError may be returned on an error.
Returns true if the given id represents the primary key of a record in the database, false otherwise. Example:
Person.exists?(5)
Find operates with three different retreval approaches:
All approaches accepts an option hash as their last parameter. The options are:
Examples for find by id:
Person.find(1) # returns the object for ID = 1 Person.find(1, 2, 6) # returns an array for objects with IDs in (1, 2, 6) Person.find([7, 17]) # returns an array for objects with IDs in (7, 17) Person.find([1]) # returns an array for objects the object with ID = 1 Person.find(1, :conditions => "administrator = 1", :order => "created_on DESC")
Examples for find first:
Person.find(:first) # returns the first object fetched by SELECT * FROM people Person.find(:first, :conditions => [ "user_name = ?", user_name]) Person.find(:first, :order => "created_on DESC", :offset => 5)
Examples for find all:
Person.find(:all) # returns an array of objects for all the rows fetched by SELECT * FROM people Person.find(:all, :conditions => [ "category IN (?)", categories], :limit => 50) Person.find(:all, :offset => 10, :limit => 10) Person.find(:all, :include => [ :account, :friends ])
Works like find(:all), but requires a complete SQL string. Examples:
Post.find_by_sql "SELECT p.*, c.author FROM posts p, comments c WHERE p.id = c.post_id" Post.find_by_sql ["SELECT * FROM posts WHERE author = ? AND created > ?", author_id, start_date]
Increments the specified counter by one. So DiscussionBoard.increment_counter("post_count", discussion_board_id) would increment the "post_count" counter on the board responding to discussion_board_id. This is used for caching aggregate values, so that they doesn’t need to be computed every time. Especially important for looping over a collection where each element require a number of aggregate values. Like the DiscussionBoard that needs to list both the number of posts and comments.
New objects can be instantiated as either empty (pass no construction parameter) or pre-set with attributes but not yet saved (pass a hash with key names matching the associated table column names). In both instances, valid attribute keys are determined by the column names of the associated table — hence you can’t have attributes that aren’t part of the table columns.
Defines the primary key field — can be overridden in subclasses. Overwriting will negate any effect of the primary_key_prefix_type setting, though.
Remove the connection for this class. This will close the active connection and the defined connection (if they exist). The result can be used as argument for establish_connection, for easy re-establishing of the connection.
Resets all the cached information about columns, which will cause they to be reloaded on the next request.
Specifies that the attribute by the name of attr_name should be serialized before saving to the database and unserialized after loading from the database. The serialization is done through YAML. If class_name is specified, the serialized object must be of that class on retrieval or SerializationTypeMismatch will be raised.
Returns a hash of all the attributes that have been specified for serialization as keys and their class restriction as values.
Sets the name of the inheritance column to use to the given value, or (if the value # is nil or false) to the value returned by the given block.
Example:
class Project < ActiveRecord::Base set_inheritance_column do original_inheritance_column + "_id" end end
Sets the name of the primary key column to use to the given value, or (if the value is nil or false) to the value returned by the given block.
Example:
class Project < ActiveRecord::Base set_primary_key "sysid" end
Sets the table name to use to the given value, or (if the value is nil or false) to the value returned by the given block.
Example:
class Project < ActiveRecord::Base set_table_name "project" end
Guesses the table name (in forced lower-case) based on the name of the class in the inheritance hierarchy descending directly from ActiveRecord. So if the hierarchy looks like: Reply < Message < ActiveRecord, then Message is used to guess the table name from even when called on Reply. The rules used to do the guess are handled by the Inflector class in Active Support, which knows almost all common English inflections (report a bug if your inflection isn’t covered).
Additionally, the class-level table_name_prefix is prepended to the table_name and the table_name_suffix is appended. So if you have "myapp_" as a prefix, the table name guess for an Account class becomes "myapp_accounts".
You can also overwrite this class method to allow for unguessable links, such as a Mouse class with a link to a "mice" table. Example:
class Mouse < ActiveRecord::Base set_table_name "mice" end
Finds the record from the passed id, instantly saves it with the passed attributes (if the validation permits it), and returns it. If the save fail under validations, the unsaved object is still returned.
Updates all records with the SET-part of an SQL update statement in updates and returns an integer with the number of rows updates. A subset of the records can be selected by specifying conditions. Example:
Billing.update_all "category = 'authorized', approved = 1", "author = 'David'"
Returns true if the comparison_object is the same object, or is of the same type and has the same id.
Returns the value of attribute identified by attr_name after it has been type cast (for example, "2004-12-12" in a data column is cast to a date object, like Date.new(2004, 12, 12)). (Alias for the protected read_attribute method).
Updates the attribute identified by attr_name with the specified value. (Alias for the protected write_attribute method).
Returns true if the specified attribute has been set by the user or by a database load and is neither nil nor empty? (the latter only applies to objects that responds to empty?, most notably Strings).
Returns a hash of all the attributes with their names as keys and clones of their objects as values.
Allows you to set all the attributes at once by passing in a hash with keys matching the attribute names (which again matches the column names). Sensitive attributes can be protected from this form of mass-assignment by using the attr_protected macro. Or you can alternatively specify which attributes can be accessed in with the attr_accessible macro. Then all the attributes not included in that won’t be allowed to be mass-assigned.
Returns the connection currently associated with the class. This can also be used to "borrow" the connection to do database work that isn’t easily done without going straight to SQL.
Initializes the attribute to zero if nil and subtracts one. Only makes sense for number-based attributes. Returns self.
Deletes the record in the database and freezes this instance to reflect that no changes should be made (since they can’t be persisted).
Just freeze the attributes hash, such that associations are still accessible even on destroyed records.
Delegates to id in order to allow two records of the same type and id to work with something like:
[ Person.find(1), Person.find(2), Person.find(3) ] & [ Person.find(1), Person.find(4) ] # => [ Person.find(1) ]
Every Active Record class must use "id" as their primary ID. This getter overwrites the native id method, which isn’t being used in this context.
Initializes the attribute to zero if nil and adds one. Only makes sense for number-based attributes. Returns self.
Returns true if this object hasn’t been saved yet — that is, a record for the object doesn’t exist yet.
A Person object with a name attribute can ask person.respond_to?("name"), person.respond_to?("name="), and person.respond_to?("name?") which will all return true.
Updates a single attribute and saves the record. This is especially useful for boolean flags on existing records. Note: This method is overwritten by the Validation module that’ll make sure that updates made with this method doesn’t get subjected to validation checks. Hence, attributes can be updated even if the full object isn’t valid.