Change guides to use update instead of update_attributes

7 files changed, 19 insertions, 19 deletions

diff --git a/guides/code/getting_started/app/controllers/posts_controller.rb b/guides/code/getting_started/app/controllers/posts_controller.rb
index a8ac9aba5a..b74c66ef13 100644
--- a/guides/code/getting_started/app/controllers/posts_controller.rb
+++ b/guides/code/getting_started/app/controllers/posts_controller.rb
@@ -31,7 +31,7 @@ class PostsController < ApplicationController
   def update
     @post = Post.find(params[:id])
 
-    if @post.update_attributes(params[:post])
+    if @post.update(params[:post])
       redirect_to :action => :show, :id => @post.id
     else
       render 'edit'
diff --git a/guides/source/active_record_basics.md b/guides/source/active_record_basics.md
index 883c2dda4a..c90f42c492 100644
--- a/guides/source/active_record_basics.md
+++ b/guides/source/active_record_basics.md
@@ -277,7 +277,7 @@ value, like so:
 
 ```ruby
 user = User.find_by_name('David')
-user.update_attributes(name: 'Dave')
+user.update(name: 'Dave')
 ```
 
 This is most useful when updating several attributes at once. If, on the other 
@@ -307,10 +307,10 @@ 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_attributes` take it into account when 
+the methods `create`, `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_attributes!`), which are stricter in that 
+is, `create!`, `save!` and `update!`), which are stricter in that 
 they raise the exception `ActiveRecord::RecordInvalid` if validation fails. 
 A quick example to illustrate:
 
diff --git a/guides/source/active_record_callbacks.md b/guides/source/active_record_callbacks.md
index 0a93f61f6d..20959a1a35 100644
--- a/guides/source/active_record_callbacks.md
+++ b/guides/source/active_record_callbacks.md
@@ -159,8 +159,8 @@ The following methods trigger callbacks:
 * `toggle!`
 * `update`
 * `update_attribute`
-* `update_attributes`
-* `update_attributes!`
+* `update`
+* `update!`
 * `valid?`
 
 Additionally, the `after_find` callback is triggered by the following finder methods:
diff --git a/guides/source/active_record_validations.md b/guides/source/active_record_validations.md
index 5797c93ae7..a911d6b941 100644
--- a/guides/source/active_record_validations.md
+++ b/guides/source/active_record_validations.md
@@ -117,11 +117,11 @@ database only if the object is valid:
 * `save`
 * `save!`
 * `update`
-* `update_attributes`
-* `update_attributes!`
+* `update`
+* `update!`
 
 The bang versions (e.g. `save!`) raise an exception if the record is invalid.
-The non-bang versions don't: `save` and `update_attributes` return `false`,
+The non-bang versions don't: `save` and `update` return `false`,
 `create` and `update` just return the objects.
 
 ### Skipping Validations
diff --git a/guides/source/form_helpers.md b/guides/source/form_helpers.md
index 12ef28668d..b7145c46dc 100644
--- a/guides/source/form_helpers.md
+++ b/guides/source/form_helpers.md
@@ -217,7 +217,7 @@ will produce output similar to
 <input id="person_name" name="person[name]" type="text" value="Henry"/>
 ```
 
-Upon form submission the value entered by the user will be stored in `params[:person][:name]`. The `params[:person]` hash is suitable for passing to `Person.new` or, if `@person` is an instance of Person, `@person.update_attributes`. While the name of an attribute is the most common second parameter to these helpers this is not compulsory. In the example above, as long as person objects have a `name` and a `name=` method Rails will be happy.
+Upon form submission the value entered by the user will be stored in `params[:person][:name]`. The `params[:person]` hash is suitable for passing to `Person.new` or, if `@person` is an instance of Person, `@person.update`. While the name of an attribute is the most common second parameter to these helpers this is not compulsory. In the example above, as long as person objects have a `name` and a `name=` method Rails will be happy.
 
 WARNING: You must pass the name of an instance variable, i.e. `:person` or `"person"`, not an actual instance of your model object.
 
@@ -460,7 +460,7 @@ As with other helpers, if you were to use the `select` helper on a form builder
 <%= f.select(:city_id, ...) %>
 ```
 
-WARNING: If you are using `select` (or similar helpers such as `collection_select`, `select_tag`) to set a `belongs_to` association you must pass the name of the foreign key (in the example above `city_id`), not the name of association itself. If you specify `city` instead of `city_id` Active Record will raise an error along the lines of ` ActiveRecord::AssociationTypeMismatch: City(#17815740) expected, got String(#1138750) ` when you pass the `params` hash to `Person.new` or `update_attributes`. Another way of looking at this is that form helpers only edit attributes. You should also be aware of the potential security ramifications of allowing users to edit foreign keys directly.
+WARNING: If you are using `select` (or similar helpers such as `collection_select`, `select_tag`) to set a `belongs_to` association you must pass the name of the foreign key (in the example above `city_id`), not the name of association itself. If you specify `city` instead of `city_id` Active Record will raise an error along the lines of ` ActiveRecord::AssociationTypeMismatch: City(#17815740) expected, got String(#1138750) ` when you pass the `params` hash to `Person.new` or `update`. Another way of looking at this is that form helpers only edit attributes. You should also be aware of the potential security ramifications of allowing users to edit foreign keys directly.
 
 ### Option Tags from a Collection of Arbitrary Objects
 
@@ -556,7 +556,7 @@ which results in a `params` hash like
 {:person => {'birth_date(1i)' => '2008', 'birth_date(2i)' => '11', 'birth_date(3i)' => '22'}}
 ```
 
-When this is passed to `Person.new` (or `update_attributes`), Active Record spots that these parameters should all be used to construct the `birth_date` attribute and uses the suffixed information to determine in which order it should pass these parameters to functions such as `Date.civil`.
+When this is passed to `Person.new` (or `update`), Active Record spots that these parameters should all be used to construct the `birth_date` attribute and uses the suffixed information to determine in which order it should pass these parameters to functions such as `Date.civil`.
 
 ### Common Options
 
diff --git a/guides/source/getting_started.md b/guides/source/getting_started.md
index 02ec024e5b..aa841d5867 100644
--- a/guides/source/getting_started.md
+++ b/guides/source/getting_started.md
@@ -882,7 +882,7 @@ And then create the `update` action in `app/controllers/posts_controller.rb`:
 def update
   @post = Post.find(params[:id])
 
-  if @post.update_attributes(params[:post])
+  if @post.update(params[:post])
     redirect_to action: :show, id: @post.id
   else
     render 'edit'
@@ -890,13 +890,13 @@ def update
 end
 ```
 
-The new method, `update_attributes`, is used when you want to update a record
+The new method, `update`, is used when you want to update a record
 that already exists, and it accepts a hash containing the attributes
 that you want to update. As before, if there was an error updating the
 post we want to show the form back to the user.
 
-TIP: You don't need to pass all attributes to `update_attributes`. For
-example, if you'd call `@post.update_attributes(title: 'A new title')`
+TIP: You don't need to pass all attributes to `update`. For
+example, if you'd call `@post.update(title: 'A new title')`
 Rails would only update the `title` attribute, leaving all other
 attributes untouched.
 
diff --git a/guides/source/layouts_and_rendering.md b/guides/source/layouts_and_rendering.md
index 0875941e29..fa303745b8 100644
--- a/guides/source/layouts_and_rendering.md
+++ b/guides/source/layouts_and_rendering.md
@@ -137,7 +137,7 @@ If you want to render the view that corresponds to a different template within t
 ```ruby
 def update
   @book = Book.find(params[:id])
-  if @book.update_attributes(params[:book])
+  if @book.update(params[:book])
     redirect_to(@book)
   else
     render "edit"
@@ -145,14 +145,14 @@ def update
 end
 ```
 
-If the call to `update_attributes` fails, calling the `update` action in this controller will render the `edit.html.erb` template belonging to the same controller.
+If the call to `update` fails, calling the `update` action in this controller will render the `edit.html.erb` template belonging to the same controller.
 
 If you prefer, you can use a symbol instead of a string to specify the action to render:
 
 ```ruby
 def update
   @book = Book.find(params[:id])
-  if @book.update_attributes(params[:book])
+  if @book.update(params[:book])
     redirect_to(@book)
   else
     render :edit