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 files/activerecord/README_rdoc.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 an HTTP request. It works like this:

Conditions

Conditions can either be specified as a string, array, or hash 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. The hash form works much like the
array form, except only equality and range is possible. Examples:

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 an
HTTP request. The authenticate_safely and
authenticate_safely_simply both 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:

Overwriting default accessors

All column values are automatically available through basic accessors on
the Active Record object, but
sometimes you want to specialize this behavior. This can be done by
overwriting the default accessors (using the same name as the attribute)
and calling super to actually change things.

class Song<ActiveRecord::Base# Uses an integer of seconds to hold the length of the songdef length=(minutes)super(minutes.to_i*60)enddef lengthsuper/ 60
end
end

Attribute query methods

In addition to the basic accessors, query methods are also automatically
available on the Active Record
object. Query methods allow you to test whether an attribute value is
present. For numeric values, present is defined as non-zero.

For example, an Active RecordUser with the name attribute has a
name? method that you can call to determine whether the user has a
name:

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 allattributes 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 mildly deprecated way of getting
(and/or creating) objects by simple queries without turning to SQL. They
work by appending the name of an attribute to find_by_ like
Person.find_by_user_name. Instead of writing
Person.find_by(user_name: user_name), you can use
Person.find_by_user_name(user_name).

It’s possible to add an exclamation point (!) on the end of the dynamic
finders to get them to raise an ActiveRecord::RecordNotFound
error if they do not return any records, like
Person.find_by_last_name!.

It’s also possible to use multiple attributes in the same find by separating them with
“and”.

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.

AssociationTypeMismatch
- The object assigned to the association wasn’t of the type specified in
the association definition.

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.

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. Some find calls do not raise
this exception to signal nothing was found, please check its documentation
for further details.

StatementInvalid - The
database server rejected the SQL statement. The precise error is added in
the message.

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.

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!