| VALID_FIND_OPTIONS | = | [ :conditions, :include, :joins, :limit, :offset, :order, :select, :readonly, :group, :from, :lock ] |
| [RW] | abstract_class | Set this to true if this is an abstract class (see #abstract_class?). |
| [RW] | pluralize_table_names | |
| [RW] | pluralize_table_names | |
| [RW] | pluralize_table_names | |
| [RW] | pluralize_table_names |
Overwrite the default class equality method to provide support for association proxies.
Returns whether this class is a base AR class. If A is a base class and B descends from A, then B.base_class will return B.
Similar to the attr_protected macro, this protects attributes of your model from mass-assignment, such as new(attributes) and attributes=(attributes) however, it does it in the opposite way. This locks all attributes and only allows access to the attributes specified. Assignment to attributes not in this list will be ignored and need to be set using the direct writer methods instead. This is meant to protect sensitive attributes from being overwritten by URL/form hackers. If you’d rather start from an all-open default and restrict attributes as needed, have a look at attr_protected.
*attributes A comma separated list of symbols that represent columns not to be protected
class Customer < ActiveRecord::Base
attr_accessible :name, :nickname
end
customer = Customer.new(:name => "David", :nickname => "Dave", :credit_rating => "Excellent")
customer.credit_rating # => nil
customer.attributes = { :name => "Jolly fellow", :credit_rating => "Superb" }
customer.credit_rating # => nil
customer.credit_rating = "Average"
customer.credit_rating # => "Average"
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 from being 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"
To start from an all-closed default and enable attributes as needed, have a look at attr_accessible.
Attributes listed as readonly can be set for a new record, but will be ignored in database updates afterwards.
Returns the base AR subclass that this class descends from. If A extends AR::Base, A.base_class will return A. If B descends from A through some arbitrarily deep hierarchy, B.base_class will return A.
Log and benchmark multiple statements in a single block. Example:
Project.benchmark("Creating project") do
project = Project.create("name" => "stuff")
project.create_manager("name" => "David")
project.milestones << Milestone.find(:all)
end
The benchmark is only recorded if the current level of the logger matches the log_level, which makes it easy to include benchmarking statements in production software that will remain inexpensive because the benchmark will only be conducted if the log level is low enough.
The logging of the multiple statements is turned off unless use_silence is set to false.
Clears the cache which maps classes to connections.
Returns an array of column objects for the table associated with this class.
Returns a hash of column objects for the table associated with this class.
Returns true if a connection that’s accessible to this class has already been opened.
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 column objects where the primary id, all columns ending in "_id" or "_count", and columns used for single table inheritance have been removed.
Returns the result of an SQL statement that should only include a COUNT(*) in the SELECT part. The use of this method should be restricted to complicated SQL queries that can’t be executed using the ActiveRecord::Calculations class methods. Look into those before using this.
sql: An SQL statement which should return a count query from the database, see the example below
Product.count_by_sql "SELECT COUNT(*) FROM sales s, customers c WHERE s.customer_id = c.id"
Creates an object (or multiple objects) and saves it to the database, if validations pass. The resulting object is returned whether the object was saved successfully to the database or not.
The attributes parameter can be either be a Hash or an Array of Hashes. These Hashes describe the attributes on the objects that are to be created.
# Create a single new object
User.create(:first_name => 'Jamie')
# Create an Array of new objects
User.create([{:first_name => 'Jamie'}, {:first_name => 'Jeremy'}])
Decrement a number field by one, usually representing a count.
This works the same as increment_counter but reduces the column value by 1 instead of increasing it.
counter_name The name of the field that should be decremented id The id of the object that should be decremented
# Decrement the post_count column for the record with an id of 5 DiscussionBoard.decrement_counter(:post_count, 5)
Delete an object (or multiple objects) where the id given matches the primary_key. A SQL DELETE command is executed on the database which means that no callbacks are fired off running this. This is an efficient method of deleting records that don’t need cleaning up after or other actions to be taken.
Objects are not instantiated with this method.
id Can be either an Integer or an Array of Integers
# Delete a single object Todo.delete(1) # Delete multiple objects todos = [1,2,3] Todo.delete(todos)
Deletes all the records that match the conditions without instantiating the objects first (and hence not calling the destroy method). Example:
Post.delete_all "person_id = 5 AND (category = 'Something' OR category = 'Else')"
True if this isn’t a concrete subclass needing a STI type condition.
Destroy an object (or multiple objects) that has the given id, the object is instantiated first, therefore all callbacks and filters are fired off before the object is deleted. This method is less efficient than ActiveRecord#delete but allows cleanup methods and other actions to be run.
This essentially finds the object (or multiple objects) with the given id, creates a new object from the attributes, and then calls destroy on it.
id Can be either an Integer or an Array of Integers
# Destroy a single object Todo.destroy(1) # Destroy multiple objects todos = [1,2,3] Todo.destroy(todos)
Destroys the objects for all the records that match the conditions 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",
:database => "path/to/dbfile"
)
Also accepts keys as strings (for parsing from yaml for example):
ActiveRecord::Base.establish_connection(
"adapter" => "sqlite",
"database" => "path/to/dbfile"
)
The exceptions AdapterNotSpecified, AdapterNotFound and ArgumentError may be returned on an error.
Checks whether a record exists in the database that matches conditions given. These conditions can either be a single integer representing a primary key id to be found, or a condition to be matched like using ActiveRecord#find.
The id_or_conditions parameter can be an Integer or a String if you want to search the primary key column of the table for a matching id, or if you’re looking to match against a condition you can use an Array or a Hash.
Possible gotcha: You can’t pass in a condition as a string e.g. "name = ‘Jamie’", this would be sanitized and then queried against the primary key column as "id = ‘name = \’Jamie"
Person.exists?(5)
Person.exists?('5')
Person.exists?(:name => "David")
Person.exists?(['name LIKE ?', "%#{query}%"])
Find operates with three different retrieval approaches:
All approaches accept an options 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 the object with ID = 1 Person.find(1, :conditions => "administrator = 1", :order => "created_on DESC")
Note that returned records may not be in the same order as the ids you provide since database rows are unordered. Give an explicit :order to ensure the results are sorted.
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 ]) Person.find(:all, :group => "category")
Example for find with a lock. Imagine two concurrent transactions: each will read person.visits == 2, add 1 to it, and save, resulting in two saves of person.visits = 3. By locking the row, the second transaction has to wait until the first is finished; we get the expected person.visits == 4.
Person.transaction do
person = Person.find(1, :lock => true)
person.visits += 1
person.save!
end
Executes a custom sql query against your database and returns all the results. The results will be returned as an array with columns requested encapsulated as attributes of the model you call this method from. If you call +Product.find_by_sql+ then the results will be returned in a Product object with the attributes you specified in the SQL query.
If you call a complicated SQL query which spans multiple tables the columns specified by the SELECT will be attributes of the model, whether or not they are columns of the corresponding table.
The sql parameter is a full sql query as a string. It will be called as is, there will be no database agnostic conversions performed. This should be a last resort because using, for example, MySQL specific terms will lock you to using that particular database engine or require you to change your call if you switch engines
# A simple sql query spanning multiple tables
Post.find_by_sql "SELECT p.title, c.author FROM posts p, comments c WHERE p.id = c.post_id"
> [#<Post:0x36bff9c @attributes={"title"=>"Ruby Meetup", "first_name"=>"Quentin"}>, ...]
# You can use the same string replacement techniques as you can with ActiveRecord#find
Post.find_by_sql ["SELECT title FROM posts WHERE author = ? AND created > ?", author_id, start_date]
> [#<Post:0x36bff9c @attributes={"first_name"=>"The Cheap Man Buys Twice"}>, ...]
Increment a number field by one, usually representing a count.
This is used for caching aggregate values, so that they don’t need to be computed every time. For example, a DiscussionBoard may cache post_count and comment_count otherwise every time the board is shown it would have to run an SQL query to find how many posts and comments there are.
counter_name The name of the field that should be incremented id The id of the object that should be incremented
# Increment the post_count column for the record with an id of 5 DiscussionBoard.increment_counter(:post_count, 5)
Defines the column name for use with single table inheritance — can be set in subclasses like so: self.inheritance_column = "type_id"
Returns a string like ‘Post id:integer, title:string, body:text’
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.
Returns an array of all the attributes that have been specified as readonly.
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 an argument for establish_connection, for easily re-establishing the connection.
Resets all the cached information about columns, which will cause them to be reloaded on the next request.
If you have an attribute that needs to be saved to the database as an object, and retrieved as the same object, then specify the name of that attribute using this method and it will be handled automatically. 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.
attr_name The field name that should be serialized class_name Optional, class name that the object type should be equal to
# Serialize a preferences attribute
class User
serialize :preferences
end
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 name of the sequence to use when generating ids to the given value, or (if the value is nil or false) to the value returned by the given block. This is required for Oracle and is useful for any database which relies on sequences for primary key generation.
If a sequence name is not explicitly set when using Oracle or Firebird, it will default to the commonly used pattern of: #{table_name}_seq
If a sequence name is not explicitly set when using PostgreSQL, it will discover the sequence corresponding to your primary key for you.
Example:
class Project < ActiveRecord::Base
set_sequence_name "projectseq" # default would have been "project_seq"
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
Indicates whether the table associated with this class exists
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 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. You can add new inflections in config/initializers/inflections.rb.
Nested classes are given table names prefixed by the singular form of the parent’s table name. Enclosing modules are not considered. Examples:
class Invoice < ActiveRecord::Base; end; file class table_name invoice.rb Invoice invoices class Invoice < ActiveRecord::Base; class Lineitem < ActiveRecord::Base; end; end; file class table_name invoice.rb Invoice::Lineitem invoice_lineitems module Invoice; class Lineitem < ActiveRecord::Base; end; end; file class table_name invoice/lineitem.rb Invoice::Lineitem lineitems
Additionally, the class-level table_name_prefix is prepended and the table_name_suffix is appended. So if you have "myapp_" as a prefix, the table name guess for an Invoice class becomes "myapp_invoices". Invoice::Lineitem becomes "myapp_invoice_lineitems".
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
Updates an object (or multiple objects) and saves it to the database, if validations pass. The resulting object is returned whether the object was saved successfully to the database or not.
id This should be the id or an array of ids to be updated attributes This should be a Hash of attributes to be set on the object, or an array of Hashes.
# Updating one record:
Person.update(15, {:user_name => 'Samuel', :group => 'expert'})
# Updating multiple records:
people = { 1 => { "first_name" => "David" }, 2 => { "first_name" => "Jeremy"} }
Person.update(people.keys, people.values)
Updates all records with details given if they match a set of conditions supplied, limits and order can also be supplied.
updates A String of column and value pairs that will be set on any records that match conditions conditions An SQL fragment like "administrator = 1" or [ "user_name = ?", username ].
See conditions in the intro for more info.
options Additional options are :limit and/or :order, see the examples for usage.
# Update all billing objects with the 3 different attributes given
Billing.update_all( "category = 'authorized', approved = 1, author = 'David'" )
# Update records that match our conditions
Billing.update_all( "author = 'David'", "title LIKE '%Rails%'" )
# Update records that match our conditions but limit it to 5 ordered by date
Billing.update_all( "author = 'David'", "title LIKE '%Rails%'",
:order => 'created_at', :limit => 5 )
A generic "counter updater" implementation, intended primarily to be used by increment_counter and decrement_counter, but which may also be useful on its own. It simply does a direct SQL update for the record with the given ID, altering the given hash of counters by the amount given by the corresponding value:
id The id of the object you wish to update a counter on counters An Array of Hashes containing the names of the fields
to update as keys and the amount to update the field by as
values
# For the Post with id of 5, decrement the comment_count by 1, and # increment the action_count by 1 Post.update_counters 5, :comment_count => -1, :action_count => 1 # Executes the following SQL: # UPDATE posts # SET comment_count = comment_count - 1, # action_count = action_count + 1 # WHERE id = 5
Returns true if the comparison_object is the same object, or is of the same type and has the same id.
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 with the attr_accessible macro. Then all the attributes not included in that won’t be allowed to be mass-assigned.
Returns a hash of cloned attributes before typecasting and deserialization.
Returns an array of names for the attributes available on this object sorted alphabetically.
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 respond to empty?, most notably Strings).
Returns an instance of the specified klass with the attributes of the current record. This is mostly useful in relation to single-table inheritance structures where you want a subclass to appear as the superclass. This can be used along with record identification in Action Pack to allow, say, Client < Company to do something like render :partial => @client.becomes(Company) to render that instance using the companies/company partial instead of clients/client.
Note: The new instance will share a link to the same attributes as the original class. So any change to the attributes in either instance will affect the other.
Returns a clone of the record that hasn’t been assigned an id yet and is treated as a new record. Note that this is a "shallow" clone: it copies the object’s attributes only, not its associations. The extent of a "deep" clone is application-specific and is therefore left to the application to implement according to its need.
Returns the column object for the named attribute.
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).
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) ]
Returns true if the given attribute is in the attributes hash
A model instance’s primary key is always available as model.id whether you name it the default ‘id’ or set it to something else.
Initializes the attribute to zero if nil and adds one. Only makes sense for number-based attributes. Returns self.
Returns the contents of the record as a nicely formatted string.
Returns true if this object hasn’t been saved yet — that is, a record for the object doesn’t exist yet.
Returns true if the record is read only. Records loaded through joins with piggy-back attributes will be marked as read only since they cannot be saved.
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 README 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:
You can also use block initialization:
user = User.new do |u| u.name = "David" u.occupation = "Code Artist" endAnd of course you can just create a bare object and specify the attributes after the fact:
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:
class 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 def self.authenticate_safely_simply(user_name, password) find(:first, :conditions => { :user_name => user_name, :password => password }) end endThe 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:
Company.find(:first, :conditions => [ "id = :id AND name = :name AND division = :division AND created_at > :accounting_date", { :id => 3, :name => "37signals", :division => "First", :accounting_date => '2005-01-01' } ])Similarly, a simple hash without a statement will generate conditions based on equality with the SQL AND operator. For instance:
Student.find(:all, :conditions => { :first_name => "Harvey", :status => 1 }) Student.find(:all, :conditions => params[:student])A range may be used in the hash to use the SQL BETWEEN operator:
Student.find(:all, :conditions => { :grade => 9..12 })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 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 endYou can alternatively use self[:attribute]=(value) and self[:attribute] instead of write_attribute(:attribute, value) and read_attribute(:attribute) as a shorter form.
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 example, an Active Record User with the name attribute has a name? method that you can call to determine whether the user has a name:
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 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, :conditions => ["user_name = ?", user_name]), you just do Person.find_by_user_name(user_name). And instead of writing Person.find(:all, :conditions => ["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, :conditions => ["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").
The same dynamic finder style can be used to create the object if it doesn’t already exist. This dynamic finder is called with find_or_create_by_ 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")Use the find_or_initialize_by_ finder if you want to return a new record without saving it first. Example:
# No 'Winter' tag exists winter = Tag.find_or_initialize_by_name("Winter") winter.new_record? # trueTo find by a subset of the attributes to be used for instantiating a new object, pass a hash instead of a list of parameters. For example:
That will either find an existing tag named "rails", or create a new one while setting the user that created it.
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 SerializationTypeMismatchSingle table inheritance
Active Record allows inheritance by storing the name of the class in a column that by default is named "type" (can be changed by overwriting Base.inheritance_column). This means that an inheritance looking like this:
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
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 an 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
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.