TEST_CODEOWNERS/rails
3
0
Fork 0
Code Issues Pull Requests 1 Actions Packages Projects Releases Wiki Activity

Merge pull request #22626 from gsamokovarov/appliation-record-documentation-fixes

Browse Source 
Appliation record documentation fixes
This commit is contained in:
David Heinemeier Hansson 2015-12-17 12:16:07 +01:00
commit 1bfce3f29d
14 changed files with 182 additions and 162 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

16
guides/source/action_view_overview.md
View File

@ -990,11 +990,11 @@ Returns `select` and `option` tags for the collection of existing return values
Example object structure for use with this method:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
belongs_to :author
end
class Author < ActiveRecord::Base
class Author < ApplicationRecord
has_many :articles
def name_with_initial
"#{first_name.first}. #{last_name}"
@ -1026,11 +1026,11 @@ Returns `radio_button` tags for the collection of existing return values of `met
Example object structure for use with this method:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
belongs_to :author
end
class Author < ActiveRecord::Base
class Author < ApplicationRecord
has_many :articles
def name_with_initial
"#{first_name.first}. #{last_name}"
@ -1062,11 +1062,11 @@ Returns `check_box` tags for the collection of existing return values of `method
Example object structure for use with this method:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
has_and_belongs_to_many :authors
end
class Author < ActiveRecord::Base
class Author < ApplicationRecord
has_and_belongs_to_many :articles
def name_with_initial
"#{first_name.first}. #{last_name}"
@ -1099,12 +1099,12 @@ Returns a string of `option` tags, like `options_from_collection_for_select`, bu
Example object structure for use with this method:
```ruby
class Continent < ActiveRecord::Base
class Continent < ApplicationRecord
has_many :countries
# attribs: id, name
end
class Country < ActiveRecord::Base
class Country < ApplicationRecord
belongs_to :continent
# attribs: id, name, continent_id
end

12
guides/source/active_support_core_extensions.md
View File

@ -397,7 +397,7 @@ The method `with_options` provides a way to factor out common options in a serie
Given a default options hash, `with_options` yields a proxy object to a block. Within the block, methods called on the proxy are forwarded to the receiver with their options merged. For example, you get rid of the duplication in:
```ruby
class Account < ActiveRecord::Base
class Account < ApplicationRecord
has_many :customers, dependent: :destroy
has_many :products, dependent: :destroy
has_many :invoices, dependent: :destroy
@ -408,7 +408,7 @@ end
this way:
```ruby
class Account < ActiveRecord::Base
class Account < ApplicationRecord
with_options dependent: :destroy do |assoc|
assoc.has_many :customers
assoc.has_many :products
@ -568,7 +568,7 @@ NOTE: Defined in `active_support/core_ext/module/aliasing.rb`.
Model attributes have a reader, a writer, and a predicate. You can alias a model attribute having the corresponding three methods defined for you in one shot. As in other aliasing methods, the new name is the first argument, and the old name is the second (one mnemonic is that they go in the same order as if you did an assignment):
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
# You can refer to the email column as "login".
# This can be meaningful for authentication code.
alias_attribute :login, :email
@ -876,7 +876,7 @@ The macro `delegate` offers an easy way to forward methods.
Let's imagine that users in some application have login information in the `User` model but name and other data in a separate `Profile` model:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_one :profile
end
```
@ -884,7 +884,7 @@ end
With that configuration you get a user's name via their profile, `user.profile.name`, but it could be handy to still be able to access such attribute directly:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_one :profile
def name
@ -896,7 +896,7 @@ end
That is what `delegate` does for you:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_one :profile
delegate :name, to: :profile

234
guides/source/association_basics.md
View File

@ -19,10 +19,10 @@ Why Associations?
In Rails, an _association_ is a connection between two Active Record models. Why do we need associations between models? Because they make common operations simpler and easier in your code. For example, consider a simple Rails application that includes a model for customers and a model for orders. Each customer can have many orders. Without associations, the model declarations would look like this:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
end
```
@ -45,11 +45,11 @@ end
With Active Record associations, we can streamline these - and other - operations by declaratively telling Rails that there is a connection between the two models. Here's the revised code for setting up customers and orders:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, dependent: :destroy
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
```
@ -89,7 +89,7 @@ In the remainder of this guide, you'll learn how to declare and use the various
A `belongs_to` association sets up a one-to-one connection with another model, such that each instance of the declaring model "belongs to" one instance of the other model. For example, if your application includes customers and orders, and each order can be assigned to exactly one customer, you'd declare the order model this way:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
```
@ -122,7 +122,7 @@ end
A `has_one` association also sets up a one-to-one connection with another model, but with somewhat different semantics (and consequences). This association indicates that each instance of a model contains or possesses one instance of another model. For example, if each supplier in your application has only one account, you'd declare the supplier model like this:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
```
@ -164,7 +164,7 @@ end
A `has_many` association indicates a one-to-many connection with another model. You'll often find this association on the "other side" of a `belongs_to` association. This association indicates that each instance of the model has zero or more instances of another model. For example, in an application containing customers and orders, the customer model could be declared like this:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -197,17 +197,17 @@ end
A `has_many :through` association is often used to set up a many-to-many connection with another model. This association indicates that the declaring model can be matched with zero or more instances of another model by proceeding _through_ a third model. For example, consider a medical practice where patients make appointments to see physicians. The relevant association declarations could look like this:
```ruby
class Physician < ActiveRecord::Base
class Physician < ApplicationRecord
has_many :appointments
has_many :patients, through: :appointments
end
class Appointment < ActiveRecord::Base
class Appointment < ApplicationRecord
belongs_to :physician
belongs_to :patient
end
class Patient < ActiveRecord::Base
class Patient < ApplicationRecord
has_many :appointments
has_many :physicians, through: :appointments
end
@ -255,17 +255,17 @@ WARNING: Automatic deletion of join models is direct, no destroy callbacks are t
The `has_many :through` association is also useful for setting up "shortcuts" through nested `has_many` associations. For example, if a document has many sections, and a section has many paragraphs, you may sometimes want to get a simple collection of all paragraphs in the document. You could set that up this way:
```ruby
class Document < ActiveRecord::Base
class Document < ApplicationRecord
has_many :sections
has_many :paragraphs, through: :sections
end
class Section < ActiveRecord::Base
class Section < ApplicationRecord
belongs_to :document
has_many :paragraphs
end
class Paragraph < ActiveRecord::Base
class Paragraph < ApplicationRecord
belongs_to :section
end
```
@ -284,17 +284,17 @@ For example, if each supplier has one account, and each account is associated wi
supplier model could look like this:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
has_one :account_history, through: :account
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
has_one :account_history
end
class AccountHistory < ActiveRecord::Base
class AccountHistory < ApplicationRecord
belongs_to :account
end
```
@ -331,11 +331,11 @@ end
A `has_and_belongs_to_many` association creates a direct many-to-many connection with another model, with no intervening model. For example, if your application includes assemblies and parts, with each assembly having many parts and each part appearing in many assemblies, you could declare the models this way:
```ruby
class Assembly < ActiveRecord::Base
class Assembly < ApplicationRecord
has_and_belongs_to_many :parts
end
class Part < ActiveRecord::Base
class Part < ApplicationRecord
has_and_belongs_to_many :assemblies
end
```
@ -372,11 +372,11 @@ If you want to set up a one-to-one relationship between two models, you'll need
The distinction is in where you place the foreign key (it goes on the table for the class declaring the `belongs_to` association), but you should give some thought to the actual meaning of the data as well. The `has_one` relationship says that one of something is yours - that is, that something points back to you. For example, it makes more sense to say that a supplier owns an account than that an account owns a supplier. This suggests that the correct relationships are like this:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
end
```
@ -409,11 +409,11 @@ NOTE: Using `t.integer :supplier_id` makes the foreign key naming obvious and ex
Rails offers two different ways to declare a many-to-many relationship between models. The simpler way is to use `has_and_belongs_to_many`, which allows you to make the association directly:
```ruby
class Assembly < ActiveRecord::Base
class Assembly < ApplicationRecord
has_and_belongs_to_many :parts
end
class Part < ActiveRecord::Base
class Part < ApplicationRecord
has_and_belongs_to_many :assemblies
end
```
@ -421,17 +421,17 @@ end
The second way to declare a many-to-many relationship is to use `has_many :through`. This makes the association indirectly, through a join model:
```ruby
class Assembly < ActiveRecord::Base
class Assembly < ApplicationRecord
has_many :manifests
has_many :parts, through: :manifests
end
class Manifest < ActiveRecord::Base
class Manifest < ApplicationRecord
belongs_to :assembly
belongs_to :part
end
class Part < ActiveRecord::Base
class Part < ApplicationRecord
has_many :manifests
has_many :assemblies, through: :manifests
end
@ -446,15 +446,15 @@ You should use `has_many :through` if you need validations, callbacks or extra a
A slightly more advanced twist on associations is the _polymorphic association_. With polymorphic associations, a model can belong to more than one other model, on a single association. For example, you might have a picture model that belongs to either an employee model or a product model. Here's how this could be declared:
```ruby
class Picture < ActiveRecord::Base
class Picture < ApplicationRecord
belongs_to :imageable, polymorphic: true
end
class Employee < ActiveRecord::Base
class Employee < ApplicationRecord
has_many :pictures, as: :imageable
end
class Product < ActiveRecord::Base
class Product < ApplicationRecord
has_many :pictures, as: :imageable
end
```
@ -501,7 +501,7 @@ end
In designing a data model, you will sometimes find a model that should have a relation to itself. For example, you may want to store all employees in a single database model, but be able to trace relationships such as between manager and subordinates. This situation can be modeled with self-joining associations:
```ruby
class Employee < ActiveRecord::Base
class Employee < ApplicationRecord
has_many :subordinates, class_name: "Employee",
foreign_key: "manager_id"
@ -567,7 +567,7 @@ Associations are extremely useful, but they are not magic. You are responsible f
When you declare a `belongs_to` association, you need to create foreign keys as appropriate. For example, consider this model:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
```
@ -599,11 +599,11 @@ WARNING: The precedence between model names is calculated using the `<=>` operat
Whatever the name, you must manually generate the join table with an appropriate migration. For example, consider these associations:
```ruby
class Assembly < ActiveRecord::Base
class Assembly < ApplicationRecord
has_and_belongs_to_many :parts
end
class Part < ActiveRecord::Base
class Part < ApplicationRecord
has_and_belongs_to_many :assemblies
end
```
@ -646,11 +646,11 @@ By default, associations look for objects only within the current module's scope
```ruby
module MyApplication
module Business
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
end
end
@ -662,13 +662,13 @@ This will work fine, because both the `Supplier` and the `Account` class are def
```ruby
module MyApplication
module Business
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
end
module Billing
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
end
end
@ -680,14 +680,14 @@ To associate a model with a model in a different namespace, you must specify the
```ruby
module MyApplication
module Business
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account,
class_name: "MyApplication::Billing::Account"
end
end
module Billing
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier,
class_name: "MyApplication::Business::Supplier"
end
@ -700,11 +700,11 @@ end
It's normal for associations to work in two directions, requiring declaration on two different models:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
```
@ -722,11 +722,11 @@ c.first_name == o.customer.first_name # => false
This happens because `c` and `o.customer` are two different in-memory representations of the same data, and neither one is automatically refreshed from changes to the other. Active Record provides the `:inverse_of` option so that you can inform it of these relations:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, inverse_of: :customer
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, inverse_of: :orders
end
```
@ -781,7 +781,7 @@ When you declare a `belongs_to` association, the declaring class automatically g
In all of these methods, `association` is replaced with the symbol passed as the first argument to `belongs_to`. For example, given the declaration:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
```
@ -848,7 +848,7 @@ Does the same as `create_association` above, but raises `ActiveRecord::RecordInv
While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `belongs_to` association reference. Such customizations can easily be accomplished by passing options and scope blocks when you create the association. For example, this association uses two such options:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, dependent: :destroy,
counter_cache: true
end
@ -877,7 +877,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if an order belongs to a customer, but the actual name of the model containing customers is `Patron`, you'd set things up this way:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, class_name: "Patron"
end
```
@ -887,10 +887,10 @@ end
The `:counter_cache` option can be used to make finding the number of belonging objects more efficient. Consider these models:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -898,10 +898,10 @@ end
With these declarations, asking for the value of `@customer.orders.size` requires making a call to the database to perform a `COUNT(*)` query. To avoid this call, you can add a counter cache to the _belonging_ model:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, counter_cache: true
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -918,10 +918,10 @@ the `counter_cache` declaration instead of `true`. For example, to use
`count_of_orders` instead of `orders_count`:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, counter_cache: :count_of_orders
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -949,7 +949,7 @@ WARNING: You should not specify this option on a `belongs_to` association that i
By convention, Rails assumes that the column used to hold the foreign key on this model is the name of the association with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, class_name: "Patron",
foreign_key: "patron_id"
end
@ -965,11 +965,11 @@ of its tables. The `:primary_key` option allows you to specify a different colum
For example, given we have a `users` table with `guid` as the primary key. If we want a separate `todos` table to hold the foreign key `user_id` in the `guid` column, then we can use `primary_key` to achieve this like so:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
self.primary_key = 'guid' # primary key is guid and not id
end
class Todo < ActiveRecord::Base
class Todo < ApplicationRecord
belongs_to :user, primary_key: 'guid'
end
```
@ -982,11 +982,11 @@ When we execute `@user.todos.create` then the `@todo` record will have its
The `:inverse_of` option specifies the name of the `has_many` or `has_one` association that is the inverse of this association. Does not work in combination with the `:polymorphic` options.
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, inverse_of: :customer
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, inverse_of: :orders
end
```
@ -1000,11 +1000,11 @@ Passing `true` to the `:polymorphic` option indicates that this is a polymorphic
If you set the `:touch` option to `true`, then the `updated_at` or `updated_on` timestamp on the associated object will be set to the current time whenever this object is saved or destroyed:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, touch: true
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -1012,7 +1012,7 @@ end
In this case, saving or destroying an order will update the timestamp on the associated customer. You can also specify a particular timestamp attribute to update:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, touch: :orders_updated_at
end
```
@ -1031,7 +1031,7 @@ object won't be validated. By default, this option is set to `false`.
There may be times when you wish to customize the query used by `belongs_to`. Such customizations can be achieved via a scope block. For example:
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, -> { where active: true },
dependent: :destroy
end
@ -1049,7 +1049,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
The `where` method lets you specify the conditions that the associated object must meet.
```ruby
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, -> { where active: true }
end
```
@ -1059,16 +1059,16 @@ end
You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
```ruby
class LineItem < ActiveRecord::Base
class LineItem < ApplicationRecord
belongs_to :order
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
has_many :line_items
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -1076,16 +1076,16 @@ end
If you frequently retrieve customers directly from line items (`@line_item.order.customer`), then you can make your code somewhat more efficient by including customers in the association from line items to orders:
```ruby
class LineItem < ActiveRecord::Base
class LineItem < ApplicationRecord
belongs_to :order, -> { includes :customer }
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
has_many :line_items
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -1133,7 +1133,7 @@ When you declare a `has_one` association, the declaring class automatically gain
In all of these methods, `association` is replaced with the symbol passed as the first argument to `has_one`. For example, given the declaration:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
```
@ -1197,7 +1197,7 @@ Does the same as `create_association` above, but raises `ActiveRecord::RecordInv
While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_one` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, class_name: "Billing", dependent: :nullify
end
```
@ -1229,7 +1229,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a supplier has an account, but the actual name of the model containing accounts is `Billing`, you'd set things up this way:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, class_name: "Billing"
end
```
@ -1255,7 +1255,7 @@ unallowed `NULL` value.
By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, foreign_key: "supp_id"
end
```
@ -1267,11 +1267,11 @@ TIP: In any case, Rails will not create foreign key columns for you. You need to
The `:inverse_of` option specifies the name of the `belongs_to` association that is the inverse of this association. Does not work in combination with the `:through` or `:as` options.
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, inverse_of: :supplier
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier, inverse_of: :account
end
```
@ -1301,7 +1301,7 @@ If you set the `:validate` option to `true`, then associated objects will be val
There may be times when you wish to customize the query used by `has_one`. Such customizations can be achieved via a scope block. For example:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, -> { where active: true }
end
```
@ -1318,7 +1318,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
The `where` method lets you specify the conditions that the associated object must meet.
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, -> { where "confirmed = 1" }
end
```
@ -1328,16 +1328,16 @@ end
You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
belongs_to :representative
end
class Representative < ActiveRecord::Base
class Representative < ApplicationRecord
has_many :accounts
end
```
@ -1345,16 +1345,16 @@ end
If you frequently retrieve representatives directly from suppliers (`@supplier.account.representative`), then you can make your code somewhat more efficient by including representatives in the association from suppliers to accounts:
```ruby
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_one :account, -> { includes :representative }
end
class Account < ActiveRecord::Base
class Account < ApplicationRecord
belongs_to :supplier
belongs_to :representative
end
class Representative < ActiveRecord::Base
class Representative < ApplicationRecord
has_many :accounts
end
```
@ -1415,7 +1415,7 @@ When you declare a `has_many` association, the declaring class automatically gai
In all of these methods, `collection` is replaced with the symbol passed as the first argument to `has_many`, and `collection_singular` is replaced with the singularized version of that symbol. For example, given the declaration:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
```
@ -1582,7 +1582,7 @@ Does the same as `collection.create` above, but raises `ActiveRecord::RecordInva
While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_many` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, dependent: :delete_all, validate: false
end
```
@ -1615,7 +1615,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a customer has many orders, but the actual name of the model containing orders is `Transaction`, you'd set things up this way:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, class_name: "Transaction"
end
```
@ -1639,7 +1639,7 @@ Controls what happens to the associated objects when their owner is destroyed:
By convention, Rails assumes that the column used to hold the foreign key on the other model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, foreign_key: "cust_id"
end
```
@ -1651,11 +1651,11 @@ TIP: In any case, Rails will not create foreign key columns for you. You need to
The `:inverse_of` option specifies the name of the `belongs_to` association that is the inverse of this association. Does not work in combination with the `:through` or `:as` options.
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, inverse_of: :customer
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer, inverse_of: :orders
end
```
@ -1670,7 +1670,7 @@ hold the `guid` column value as the foreign key and not `id`
value. This can be achieved like this:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_many :todos, primary_key: :guid
end
```
@ -1700,7 +1700,7 @@ If you set the `:validate` option to `false`, then associated objects will not b
There may be times when you wish to customize the query used by `has_many`. Such customizations can be achieved via a scope block. For example:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, -> { where processed: true }
end
```
@ -1723,7 +1723,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
The `where` method lets you specify the conditions that the associated object must meet.
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :confirmed_orders, -> { where "confirmed = 1" },
class_name: "Order"
end
@ -1732,7 +1732,7 @@ end
You can also set conditions via a hash:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :confirmed_orders, -> { where confirmed: true },
class_name: "Order"
end
@ -1749,7 +1749,7 @@ The `extending` method specifies a named module to extend the association proxy.
The `group` method supplies an attribute name to group the result set by, using a `GROUP BY` clause in the finder SQL.
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :line_items, -> { group 'orders.id' },
through: :orders
end
@ -1760,16 +1760,16 @@ end
You can use the `includes` method to specify second-order associations that should be eager-loaded when this association is used. For example, consider these models:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
has_many :line_items
end
class LineItem < ActiveRecord::Base
class LineItem < ApplicationRecord
belongs_to :order
end
```
@ -1777,16 +1777,16 @@ end
If you frequently retrieve line items directly from customers (`@customer.orders.line_items`), then you can make your code somewhat more efficient by including line items in the association from customers to orders:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, -> { includes :line_items }
end
class Order < ActiveRecord::Base
class Order < ApplicationRecord
belongs_to :customer
has_many :line_items
end
class LineItem < ActiveRecord::Base
class LineItem < ApplicationRecord
belongs_to :order
end
```
@ -1796,7 +1796,7 @@ end
The `limit` method lets you restrict the total number of objects that will be fetched through an association.
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :recent_orders,
-> { order('order_date desc').limit(100) },
class_name: "Order",
@ -1812,7 +1812,7 @@ The `offset` method lets you specify the starting offset for fetching objects vi
The `order` method dictates the order in which associated objects will be received (in the syntax used by an SQL `ORDER BY` clause).
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, -> { order "date_confirmed DESC" }
end
```
@ -1833,7 +1833,7 @@ Use the `distinct` method to keep the collection free of duplicates. This is
mostly useful together with the `:through` option.
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_many :readings
has_many :articles, through: :readings
end
@ -1927,7 +1927,7 @@ When you declare a `has_and_belongs_to_many` association, the declaring class au
In all of these methods, `collection` is replaced with the symbol passed as the first argument to `has_and_belongs_to_many`, and `collection_singular` is replaced with the singularized version of that symbol. For example, given the declaration:
```ruby
class Part < ActiveRecord::Base
class Part < ApplicationRecord
has_and_belongs_to_many :assemblies
end
```
@ -2081,7 +2081,7 @@ Does the same as `collection.create`, but raises `ActiveRecord::RecordInvalid` i
While Rails uses intelligent defaults that will work well in most situations, there may be times when you want to customize the behavior of the `has_and_belongs_to_many` association reference. Such customizations can easily be accomplished by passing options when you create the association. For example, this association uses two such options:
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies, -> { readonly },
autosave: true
end
@ -2103,7 +2103,7 @@ By convention, Rails assumes that the column in the join table used to hold the
TIP: The `:foreign_key` and `:association_foreign_key` options are useful when setting up a many-to-many self-join. For example:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_and_belongs_to_many :friends,
class_name: "User",
foreign_key: "this_user_id",
@ -2120,7 +2120,7 @@ If you set the `:autosave` option to `true`, Rails will save any loaded members
If the name of the other model cannot be derived from the association name, you can use the `:class_name` option to supply the model name. For example, if a part has many assemblies, but the actual name of the model containing assemblies is `Gadget`, you'd set things up this way:
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies, class_name: "Gadget"
end
```
@ -2130,7 +2130,7 @@ end
By convention, Rails assumes that the column in the join table used to hold the foreign key pointing to this model is the name of this model with the suffix `_id` added. The `:foreign_key` option lets you set the name of the foreign key directly:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
has_and_belongs_to_many :friends,
class_name: "User",
foreign_key: "this_user_id",
@ -2151,7 +2151,7 @@ If you set the `:validate` option to `false`, then associated objects will not b
There may be times when you wish to customize the query used by `has_and_belongs_to_many`. Such customizations can be achieved via a scope block. For example:
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies, -> { where active: true }
end
```
@ -2174,7 +2174,7 @@ You can use any of the standard [querying methods](active_record_querying.html)
The `where` method lets you specify the conditions that the associated object must meet.
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies,
-> { where "factory = 'Seattle'" }
end
@ -2183,7 +2183,7 @@ end
You can also set conditions via a hash:
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies,
-> { where factory: 'Seattle' }
end
@ -2200,7 +2200,7 @@ The `extending` method specifies a named module to extend the association proxy.
The `group` method supplies an attribute name to group the result set by, using a `GROUP BY` clause in the finder SQL.
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies, -> { group "factory" }
end
```
@ -2214,7 +2214,7 @@ You can use the `includes` method to specify second-order associations that shou
The `limit` method lets you restrict the total number of objects that will be fetched through an association.
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies,
-> { order("created_at DESC").limit(50) }
end
@ -2229,7 +2229,7 @@ The `offset` method lets you specify the starting offset for fetching objects vi
The `order` method dictates the order in which associated objects will be received (in the syntax used by an SQL `ORDER BY` clause).
```ruby
class Parts < ActiveRecord::Base
class Parts < ApplicationRecord
has_and_belongs_to_many :assemblies,
-> { order "assembly_name ASC" }
end
@ -2271,7 +2271,7 @@ Association callbacks are similar to normal callbacks, but they are triggered by
You define association callbacks by adding options to the association declaration. For example:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, before_add: :check_credit_limit
def check_credit_limit(order)
@ -2285,7 +2285,7 @@ Rails passes the object being added or removed to the callback.
You can stack callbacks on a single event by passing them as an array:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders,
before_add: [:check_credit_limit, :calculate_shipping_charges]
@ -2306,7 +2306,7 @@ If a `before_add` callback throws an exception, the object does not get added to
You're not limited to the functionality that Rails automatically builds into association proxy objects. You can also extend these objects through anonymous modules, adding new finders, creators, or other methods. For example:
```ruby
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders do
def find_by_order_prefix(order_number)
find_by(region_id: order_number[0..2])
@ -2324,11 +2324,11 @@ module FindRecentExtension
end
end
class Customer < ActiveRecord::Base
class Customer < ApplicationRecord
has_many :orders, -> { extending FindRecentExtension }
end
class Supplier < ActiveRecord::Base
class Supplier < ApplicationRecord
has_many :deliveries, -> { extending FindRecentExtension }
end
```

8
guides/source/autoloading_and_reloading_constants.md
View File

@ -181,14 +181,14 @@ constant.
That is,
```ruby
class Project < ActiveRecord::Base
class Project < ApplicationRecord
end
```
performs a constant assignment equivalent to
```ruby
Project = Class.new(ActiveRecord::Base)
Project = Class.new(ApplicationRecord)
```
including setting the name of the class as a side-effect:
@ -912,7 +912,7 @@ these classes:
```ruby
# app/models/polygon.rb
class Polygon < ActiveRecord::Base
class Polygon < ApplicationRecord
end
# app/models/triangle.rb
@ -987,7 +987,7 @@ root class:
```ruby
# app/models/polygon.rb
class Polygon < ActiveRecord::Base
class Polygon < ApplicationRecord
end
require_dependency ‘square’
```

6
guides/source/caching_with_rails.md
View File

@ -175,11 +175,11 @@ your app will serve stale data. To fix this, we tie the models together with
the `touch` method:
```ruby
class Product < ActiveRecord::Base
class Product < ApplicationRecord
has_many :games
end
class Game < ActiveRecord::Base
class Game < ApplicationRecord
belongs_to :product, touch: true
end
```
@ -284,7 +284,7 @@ The most efficient way to implement low-level caching is using the `Rails.cache.
Consider the following example. An application has a `Product` model with an instance method that looks up the product’s price on a competing website. The data returned by this method would be perfect for low-level caching:
```ruby
class Product < ActiveRecord::Base
class Product < ApplicationRecord
def competing_price
Rails.cache.fetch("#{cache_key}/competing_price", expires_in: 12.hours) do
Competitor::API.find_price(id)

2
guides/source/debugging_rails_applications.md
View File

@ -608,7 +608,7 @@ Started GET "/" for 127.0.0.1 at 2014-04-11 13:39:23 +0200
Processing by ArticlesController#index as HTML
[1, 8] in /home/davidr/Proyectos/test_app/app/models/article.rb
1: class Article < ActiveRecord::Base
1: class Article < ApplicationRecord
2:
3: def self.find_recent(limit = 10)
4: byebug

8
guides/source/form_helpers.md
View File

@ -880,12 +880,12 @@ Many apps grow beyond simple forms editing a single object. For example, when cr
Active Record provides model level support via the `accepts_nested_attributes_for` method:
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_many :addresses
accepts_nested_attributes_for :addresses
end
class Address < ActiveRecord::Base
class Address < ApplicationRecord
belongs_to :person
end
```
@ -973,7 +973,7 @@ private
You can allow users to delete associated objects by passing `allow_destroy: true` to `accepts_nested_attributes_for`
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_many :addresses
accepts_nested_attributes_for :addresses, allow_destroy: true
end
@ -1014,7 +1014,7 @@ end
It is often useful to ignore sets of fields that the user has not filled in. You can control this by passing a `:reject_if` proc to `accepts_nested_attributes_for`. This proc will be called with each hash of attributes submitted by the form. If the proc returns `false` then Active Record will not build an associated object for that hash. The example below only tries to build an address if the `kind` attribute is set.
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_many :addresses
accepts_nested_attributes_for :addresses, reject_if: lambda {|attributes| attributes['kind'].blank?}
end

21
guides/source/getting_started.md
View File

@ -990,21 +990,22 @@ and restart the web server when a change is made.
The model file, `app/models/article.rb` is about as simple as it can get:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
end
```
There isn't much to this file - but note that the `Article` class inherits from
`ActiveRecord::Base`. Active Record supplies a great deal of functionality to
your Rails models for free, including basic database CRUD (Create, Read, Update,
Destroy) operations, data validation, as well as sophisticated search support
and the ability to relate multiple models to one another.
`ApplicationRecord`. `ApplicationRecord` inherits from `ActiveRecord::Base`
which supplies a great deal of functionality to your Rails models for free,
including basic database CRUD (Create, Read, Update, Destroy) operations, data
validation, as well as sophisticated search support and the ability to relate
multiple models to one another.
Rails includes methods to help you validate the data that you send to models.
Open the `app/models/article.rb` file and edit it:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
validates :title, presence: true,
length: { minimum: 5 }
end
@ -1529,7 +1530,7 @@ This command will generate four files:
First, take a look at `app/models/comment.rb`:
```ruby
class Comment < ActiveRecord::Base
class Comment < ApplicationRecord
belongs_to :article
end
```
@ -1587,7 +1588,7 @@ association. You've already seen the line of code inside the `Comment` model
(app/models/comment.rb) that makes each comment belong to an Article:
```ruby
class Comment < ActiveRecord::Base
class Comment < ApplicationRecord
belongs_to :article
end
```
@ -1596,7 +1597,7 @@ You'll need to edit `app/models/article.rb` to add the other side of the
association:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
has_many :comments
validates :title, presence: true,
length: { minimum: 5 }
@ -1962,7 +1963,7 @@ you to use the `dependent` option of an association to achieve this. Modify the
Article model, `app/models/article.rb`, as follows:
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
has_many :comments, dependent: :destroy
validates :title, presence: true,
length: { minimum: 5 }

2
guides/source/i18n.md
View File

@ -816,7 +816,7 @@ This gives you quite powerful means to flexibly adjust your messages to your app
Consider a User model with a validation for the name attribute like this:
```ruby
class User < ActiveRecord::Base
class User < ApplicationRecord
validates :name, presence: true
end
```

6
guides/source/nested_model_forms.md
View File

@ -32,7 +32,7 @@ For an ActiveRecord::Base model and association this writer method is commonly d
#### has_one
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_one :address
accepts_nested_attributes_for :address
end
@ -41,7 +41,7 @@ end
#### belongs_to
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
belongs_to :firm
accepts_nested_attributes_for :firm
end
@ -50,7 +50,7 @@ end
#### has_many / has_and_belongs_to_many
```ruby
class Person < ActiveRecord::Base
class Person < ApplicationRecord
has_many :projects
accepts_nested_attributes_for :projects
end

6
guides/source/routing.md
View File

@ -252,11 +252,11 @@ TIP: _If you need to use a different controller namespace inside a `namespace` b
It's common to have resources that are logically children of other resources. For example, suppose your application includes these models:
```ruby
class Magazine < ActiveRecord::Base
class Magazine < ApplicationRecord
has_many :ads
end
class Ad < ActiveRecord::Base
class Ad < ApplicationRecord
belongs_to :magazine
end
```
@ -1099,7 +1099,7 @@ You can override `ActiveRecord::Base#to_param` of a related model to construct
a URL:
```ruby
class Video < ActiveRecord::Base
class Video < ApplicationRecord
def to_param
identifier
end

2
guides/source/security.md
View File

@ -171,7 +171,7 @@ NOTE: _Sessions that never expire extend the time-frame for attacks such as cros
One possibility is to set the expiry time-stamp of the cookie with the session id. However the client can edit cookies that are stored in the web browser so expiring sessions on the server is safer. Here is an example of how to _expire sessions in a database table_. Call `Session.sweep("20 minutes")` to expire sessions that were used longer than 20 minutes ago.
```ruby
class Session < ActiveRecord::Base
class Session < ApplicationRecord
def self.sweep(time = 1.hour)
if time.is_a?(String)
time = time.split.inject { |count, unit| count.to_i.send(unit) }

2
guides/source/testing.md
View File

@ -177,7 +177,7 @@ Saved the article without a title
Now to get this test to pass we can add a model level validation for the _title_ field.
```ruby
class Article < ActiveRecord::Base
class Article < ApplicationRecord
validates :title, presence: true
end
```

19
guides/source/upgrading_ruby_on_rails.md
View File

@ -53,6 +53,25 @@ Don't forget to review the difference, to see if there were any unexpected chang
Upgrading from Rails 4.2 to Rails 5.0
-------------------------------------
### Active Record models now inherit from ApplicationRecord by default
In Rails 4.2 an Active Job inherits from `ActiveRecord::Base`. In Rails 5.0 models
inherit from `ApplicationRecord`.
`ApplicationRecord` is a new superclass for all app models, analogous to app
controllers subclassing ApplicationController instead of
ActionController::Base. This gives apps a single spot to configure app-wide
model behavior
When upgrading from Rails 4.2 to Rails 5.0 you need to create an
`application_record.rb` file in `app/models/` and add the following content:
```
class ApplicationRecord < ActiveRecord::Base
self.abstract_class = true
end
```
### Halting callback chains via `throw(:abort)`
In Rails 4.2, when a 'before' callback returns `false` in Active Record