`widgets` table is being created in `primary_keys_test.rb` for PostgreSQLAdapter, MysqlAdapter, Mysql2Adapter
    and it makes test to fail earlier.

    Before:
      `bundle exec rake mysql2:test`

    ```
    Finished in 127.287669s, 35.5258 runs/s, 97.8885 assertions/s.

      1) Error:
    PersistenceTest::SaveTest#test_save_touch_false:
    ActiveModel::UnknownAttributeError: unknown attribute 'name' for #<Class:0x0000000a7d6ef0>.
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:36:in `rescue in _assign_attribute'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:34:in `_assign_attribute'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:40:in `block in _assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `each'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:39:in `_assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/attribute_assignment.rb:26:in `_assign_attributes'
        /home/kd/projects/kd-rails/activemodel/lib/active_model/attribute_assignment.rb:33:in `assign_attributes'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/core.rb:293:in `initialize'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/inheritance.rb:61:in `new'
        /home/kd/projects/kd-rails/activerecord/lib/active_record/persistence.rb:50:in `create!'
        /home/kd/projects/kd-rails/activerecord/test/cases/persistence_test.rb:913:in `test_save_touch_false'

    4522 runs, 12460 assertions, 0 failures, 1 errors, 4 skips
    ```

    After:
      `bundle exec rake mysql2:test`

    ```
       Finished in 135.785086s, 33.3026 runs/s, 91.7774 assertions/s.

       4522 runs, 12462 assertions, 0 failures, 0 errors, 4 skips
    ```

I’m renaming all instances of `use_transcational_fixtures` to
`use_transactional_tests` and “transactional fixtures” to
“transactional tests”.

I’m deprecating `use_transactional_fixtures=`. So anyone who is
explicitly setting this will get a warning telling them to use
`use_transactional_tests=` instead.

I’m maintaining backwards compatibility—both forms will work.
`use_transactional_tests` will check to see if
`use_transactional_fixtures` is set and use that, otherwise it will use
itself. But because `use_transactional_tests` is a class attribute
(created with `class_attribute`) this requires a little bit of hoop
jumping. The writer method that `class_attribute` generates defines a
new reader method that return the value being set. Which means we can’t
set the default of `true` using `use_transactional_tests=` as was done
previously because that won’t take into account anyone using
`use_transactional_fixtures`. Instead I defined the reader method
manually and it checks `use_transactional_fixtures`. If it was set then
it should be used, otherwise it should return the default, which is
`true`. If someone uses `use_transactional_tests=` then it will
overwrite the backwards-compatible method with whatever they set.

 - This is based on https://github.com/rails/rails/issues/18400 but
   tackling same issue with update_attribute method instead of update method.

- Right now, there is no method to update multiple records with
  validations and callbacks.
- Changed the behavior of existing `update` method so that when `id`
  attribute is not given and the method is called on an `Relation`
  object, it will execute update for every record of the `Relation` and
  will run validations and callbacks for every record.
- Added test case for validating that the callbacks run when `update` is
  called on a `Relation`.
- Changed test_create_columns_not_equal_attributes test from
  persistence_test to include author_name column on topics table as it
  it used in before_update callback.
- This change introduces performance issues when a large number of
  records are to be updated because it runs UPDATE query for every
  record of the result. The `update_all` method can be used in that case
  if callbacks are not required because it will only run single UPDATE
  for all the records.

`Computer` class needs to be require

See #17217 for more details

One of the author fixture we have ("david") references an author address by ID.
Since we disable FK checks when inserting fixtures, this is all fine until we
try to update it, at which point MySQL would complain about the missing row
referenced by the `author_address_id`.

[Godfrey Chan, Matthew Draper]

`reload` is meant to put a record in the same state it would be if you
were to do `Post.find(post.id)`. This means we should fully replace the
attributes hash.

There's a lot more that can be moved to these, but this felt like a good
place to introduce the object. Plans are:

- Remove all knowledge of type casting from the columns, beyond a
  reference to the cast_type
- Move type_cast_for_database to these objects
- Potentially make them mutable, introduce a state machine, and have
  dirty checking handled here as well
- Move `attribute`, `decorate_attribute`, and anything else that
  modifies types to mess with this object, not the columns hash
- Introduce a collection object to manage these, reduce allocations, and
  not require serializing the types

Topics call `serialize :content`, which means that the values in the
database should be YAML encoded, and we would only expect to receive
YAML strings to `update_column` and `update_columns`.

`@raw_attributes` should not contain the type-cast, mutable version of
the value.

Closes #15122
Closes #15107

This case prevents against regressions. The change was suggested in a recent
PR but the all our tests passed.

Also change other related test to use existing record rather than
creating new one.

Avoid rounding problems with `.usec` method rounding the seconds when the
field doesn't persist the `.usec` piece.

Without this, the original record's values won't get saved, since the partial insertions support (https://github.com/rails/rails/commit/144e8691cbfb8bba77f18cfe68d5e7fd48887f5e) checks for changed values and thinks there are none.

The method got extracted out from AR::Base in commit
d916c62c, but the tests never did.

It was added because a regression caused by a712e08e

Closes #9255

When applying default_scope to a class with a where clause, using
update_column(s) could generate a query that would not properly update
the record due to the where clause from the default_scope being applied
to the update query.

    class User < ActiveRecord::Base
      default_scope where(active: true)
    end

    user = User.first
    user.active = false
    user.save!

    user.update_column(:active, true) # => false

In this situation we want to skip the default_scope clause and just
update the record based on the primary key. With this change:

    user.update_column(:active, true) # => true

Fixes #8436.

If you want to change the STI type too, use AR::Base.becomes! instead

Didn't work before because it updated the model-in-memory first, so the DB query couldn't find the record.