aboutsummaryrefslogtreecommitdiffstats
path: root/guides/source/active_record_basics.md
diff options
context:
space:
mode:
Diffstat (limited to 'guides/source/active_record_basics.md')
-rw-r--r--guides/source/active_record_basics.md83
1 files changed, 43 insertions, 40 deletions
diff --git a/guides/source/active_record_basics.md b/guides/source/active_record_basics.md
index fc8fac4651..9d2ba328ea 100644
--- a/guides/source/active_record_basics.md
+++ b/guides/source/active_record_basics.md
@@ -1,3 +1,5 @@
+**DO NOT READ THIS FILE IN GITHUB, GUIDES ARE PUBLISHED IN http://guides.rubyonrails.org.**
+
Active Record Basics
====================
@@ -31,7 +33,7 @@ Object Relational Mapping system.
in his book _Patterns of Enterprise Application Architecture_. In
Active Record, objects carry both persistent data and behavior which
operates on that data. Active Record takes the opinion that ensuring
-data access logic is part of the object will educate users of that
+data access logic as part of the object will educate users of that
object on how to write to and read from the database.
### Object Relational Mapping
@@ -48,10 +50,10 @@ overall database access code.
Active Record gives us several mechanisms, the most important being the ability
to:
-* Represent models and their data
-* Represent associations between these models
-* Represent inheritance hierarchies through related models
-* Validate models before they get persisted to the database
+* Represent models and their data.
+* Represent associations between these models.
+* Represent inheritance hierarchies through related models.
+* Validate models before they get persisted to the database.
* Perform database operations in an object-oriented fashion.
Convention over Configuration in Active Record
@@ -62,9 +64,9 @@ may be necessary to write a lot of configuration code. This is particularly true
for ORM frameworks in general. However, if you follow the conventions adopted by
Rails, you'll need to write very little configuration (in some case no
configuration at all) when creating Active Record models. The idea is that if
-you configure your applications in the very same way most of the times then this
-should be the default way. In this cases, explicit configuration would be needed
-only in those cases where you can't follow the conventions for any reason.
+you configure your applications in the very same way most of the time then this
+should be the default way. Thus, explicit configuration would be needed
+only in those cases where you can't follow the standard convention.
### Naming Conventions
@@ -78,17 +80,17 @@ of two or more words, the model class name should follow the Ruby conventions,
using the CamelCase form, while the table name must contain the words separated
by underscores. Examples:
-* Database Table - Plural with underscores separating words (e.g., `book_clubs`)
+* Database Table - Plural with underscores separating words (e.g., `book_clubs`).
* Model Class - Singular with the first letter of each word capitalized (e.g.,
-`BookClub`)
+`BookClub`).
-| Model / Class | Table / Schema |
-| ------------- | -------------- |
-| `Post` | `posts` |
-| `LineItem` | `line_items` |
-| `Deer` | `deer` |
-| `Mouse` | `mice` |
-| `Person` | `people` |
+| Model / Class | Table / Schema |
+| ---------------- | -------------- |
+| `Article` | `articles` |
+| `LineItem` | `line_items` |
+| `Deer` | `deers` |
+| `Mouse` | `mice` |
+| `Person` | `people` |
### Schema Conventions
@@ -101,11 +103,11 @@ depending on the purpose of these columns.
fields that Active Record will look for when you create associations between
your models.
* **Primary keys** - By default, Active Record will use an integer column named
- `id` as the table's primary key. When using [Rails
+ `id` as the table's primary key. When using [Active Record
Migrations](migrations.html) to create your tables, this column will be
automatically created.
-There are also some optional column names that will create additional features
+There are also some optional column names that will add additional features
to Active Record instances:
* `created_at` - Automatically gets set to the current date and time when the
@@ -116,13 +118,13 @@ to Active Record instances:
locking](http://api.rubyonrails.org/classes/ActiveRecord/Locking.html) to
a model.
* `type` - Specifies that the model uses [Single Table
- Inheritance](http://api.rubyonrails.org/classes/ActiveRecord/Base.html)
+ Inheritance](http://api.rubyonrails.org/classes/ActiveRecord/Base.html#class-ActiveRecord::Base-label-Single+table+inheritance).
* `(association_name)_type` - Stores the type for
[polymorphic associations](association_basics.html#polymorphic-associations).
* `(table_name)_count` - Used to cache the number of belonging objects on
- associations. For example, a `comments_count` column in a `Post` class that
+ associations. For example, a `comments_count` column in a `Articles` class that
has many instances of `Comment` will cache the number of existent comments
- for each post.
+ for each article.
NOTE: While these column names are optional, they are in fact reserved by Active Record. Steer clear of reserved keywords unless you want the extra functionality. For example, `type` is a reserved keyword used to designate a table using Single Table Inheritance (STI). If you are not using STI, try an analogous keyword like "context", that may still accurately describe the data you are modeling.
@@ -181,18 +183,18 @@ definition:
```ruby
class FunnyJoke < ActiveSupport::TestCase
- set_fixture_class funny_jokes: 'Joke'
+ set_fixture_class funny_jokes: Joke
fixtures :funny_jokes
...
end
```
It's also possible to override the column that should be used as the table's
-primary key using the `ActiveRecord::Base.set_primary_key` method:
+primary key using the `ActiveRecord::Base.primary_key=` method:
```ruby
class Product < ActiveRecord::Base
- set_primary_key "product_id"
+ self.primary_key = "product_id"
end
```
@@ -253,7 +255,7 @@ user = User.first
```ruby
# return the first user named David
-david = User.find_by_name('David')
+david = User.find_by(name: 'David')
```
```ruby
@@ -270,7 +272,7 @@ Once an Active Record object has been retrieved, its attributes can be modified
and it can be saved to the database.
```ruby
-user = User.find_by_name('David')
+user = User.find_by(name: 'David')
user.name = 'Dave'
user.save
```
@@ -279,7 +281,7 @@ A shorthand for this is to use a hash mapping attribute names to the desired
value, like so:
```ruby
-user = User.find_by_name('David')
+user = User.find_by(name: 'David')
user.update(name: 'Dave')
```
@@ -297,7 +299,7 @@ Likewise, once retrieved an Active Record object can be destroyed which removes
it from the database.
```ruby
-user = User.find_by_name('David')
+user = User.find_by(name: 'David')
user.destroy
```
@@ -309,11 +311,11 @@ into the database. There are several methods that you can use to check your
models and validate that an attribute value is not empty, is unique and not
already in the database, follows a specific format and many more.
-Validation is a very important issue to consider when persisting to database, so
-the methods `create`, `save` and `update` take it into account when
+Validation is a very important issue to consider when persisting to the database, so
+the methods `save` and `update` take it into account when
running: they return `false` when validation fails and they didn't actually
-perform any operation on database. All of these have a bang counterpart (that
-is, `create!`, `save!` and `update!`), which are stricter in that
+perform any operation on the database. All of these have a bang counterpart (that
+is, `save!` and `update!`), which are stricter in that
they raise the exception `ActiveRecord::RecordInvalid` if validation fails.
A quick example to illustrate:
@@ -322,8 +324,9 @@ class User < ActiveRecord::Base
validates :name, presence: true
end
-User.create # => false
-User.create! # => ActiveRecord::RecordInvalid: Validation failed: Name can't be blank
+user = User.new
+user.save # => false
+user.save! # => ActiveRecord::RecordInvalid: Validation failed: Name can't be blank
```
You can learn more about validations in the [Active Record Validations
@@ -343,7 +346,7 @@ Migrations
Rails provides a domain-specific language for managing a database schema called
migrations. Migrations are stored in files which are executed against any
-database that Active Record support using `rake`. Here's a migration that
+database that Active Record supports using `rake`. Here's a migration that
creates a table:
```ruby
@@ -357,7 +360,7 @@ class CreatePublications < ActiveRecord::Migration
t.string :publisher_type
t.boolean :single_issue
- t.timestamps
+ t.timestamps null: false
end
add_index :publications, :publication_type_id
end
@@ -368,6 +371,6 @@ Rails keeps track of which files have been committed to the database and
provides rollback features. To actually create the table, you'd run `rake db:migrate`
and to roll it back, `rake db:rollback`.
-Note that the above code is database-agnostic: it will run in MySQL, postgresql,
-Oracle and others. You can learn more about migrations in the [Active Record
-Migrations guide](migrations.html)
+Note that the above code is database-agnostic: it will run in MySQL,
+PostgreSQL, Oracle and others. You can learn more about migrations in the
+[Active Record Migrations guide](migrations.html).