Race conditions can occur when an ActiveRecord is destroyed
twice or destroyed and updated. The callbacks should only be
triggered once, similar to a SQL database trigger.

- If aliased, then use the aliased attribute name.

- If aliased, then use the aliased attribute name.
- Fixes #26417.

The alternative is escaping it but moving around the text seems a bit simpler.

While working on updating Paper Trail for 5.1 compatibility, I noticed
that I was required to pass a second argument to `attribute`. I didn't
intend for this to be the case, as `attribute :foo` is totally
reasonable shorthand for "I want `attr_accessor :foo`, but also have it
work with things like `.attributes` and `ActiveRecord::Dirty`"

Fixes #27125.

https://gist.github.com/sergey-alekseev/946657ebdb5e58d1bee115714056ec96

Fixes casting of IDs to the data type of the association primary key,
rather than then the data type of the model's primary key. (Tests use a
string primary key on the association, rather than an int.)

Tests issue #20995

9c9fb19b changed the behaviour of the _ids= setters for associations to
raise an AssociationTypeMismatch when unknown IDs are given:

    Class: <ActiveRecord::AssociationTypeMismatch>
    Message: <"Developer(#43811860) expected, got NilClass(#16732720)">

This restores the original ActiveRecord::RecordNotFound exception with a
much clearer error message:

    Class: <ActiveRecord::RecordNotFound>
    Message: <"Couldn't find all Developers with 'id': (1, -9999) [WHERE \"contracts\".\"company_id\" = ?] (found 1 results, but was looking for 2)">

Fixes #25719

Since 9.4, PostgreSQL recommends using `pgcrypto`'s `gen_random_uuid()`
to generate version 4 UUIDs instead of the functions in the `uuid-ossp`
extension.

These changes uses the appropriate UUID function depending on the
underlying PostgreSQL server's version, while maintaining
`uuid_generate_v4()` in older migrations.

This patch brings back the functionality of passing true to the
association proxy. The behavior was deprecated with #20888 and scheduled
for removal in Rails 5.1.

The deprecation mentioned that instead of `Article.category(true)` one
should use `article#reload.category`. Unfortunately the alternative does
not expose the same behavior as passing true to the reader
did. Specifically reloading the parent record throws unsaved changes and
other caches away. Passing true only affected the association.

This is problematic and there is no easy workaround. I propose to bring
back the old functionality by introducing this new reader method for
singular associations.

https://github.com/rails/rails/commit/fc4c15d823b112cc440cbd9a4288e1a389c138da

As reported via #26904, there is a regression in how values for
Postgres' HStore column type are being processed, beginning in Rails 5.
Currently, the way that Active Record checks whether or not values need
to be serialized and put into the correct storage format is whether or
not it is a `Hash` object. Since `ActionController::Parameters` no
longer inherits from `Hash` in Rails 5, this conditional now returns
false. To remedy this, we are now checking to see whether the `value`
parameters being passed in responds to a certain method, and then
calling the `serialize` method, except this time with a real Hash
object. Keeping things DRY!

Fixes #26904.

Records fetching order is very important for performance if `limit` is
presented. Should not except the order in the case.

And `exists?` replaces select list to `1 AS one` therefore `:distinct`
is useless (`DISTINCT 1 AS one`). And PostgreSQL raises the following
error if `:distinct` and `:order` are used in the same time.

```
ERROR:  for SELECT DISTINCT, ORDER BY expressions must appear in select list
```

If `limit_value` is presented, records fetching order is very important
for performance. Should not unscope the order in the case.

This reverts commit 671eb742.

This is not a change we would like moving forward.

- CollectionAssociation#select was removed in
  https://github.com/rails/rails/pull/25989 in favor of
  QueryMethods#select but it caused a regression when passing arguments
  to select and a block.
- This used to work earlier in Rails 4.2 and Rails 5. See gist
  https://gist.github.com/prathamesh-sonpatki/a7df922273473a77dfbc742a4be4b618.
- This commit restores the behavior of Rails 4.2 and Rails 5.0.0 to
  allow passing arguments and block at the same time but also deprecates
  it.
- Because, these arguments do not have any effect on the output of
  select when select is used with a block.
- Updated documentation to remove the example passing arguments and
  block at the same time to `CollectionProxy#select`.

ie. DecimalWithoutScale, Text and UnsignedInteger

ActiveModel::Type)

Some code was previously referring to ActiveModel::Type::*. This could
cause issues in the future if any of the ActiveRecord::Type classes were
overridden in the future.

Test: JSON attribute value nil can be used in where(attr: nil)

Add changelog entry

- If the attribute is not changed, then update_attribute does not run
  SQL query, this effectively means that no change was made to the
  attribute.
- This change was made in https://github.com/rails/rails/commit/0fcd4cf5
  to avoid a SQL call.
- But the change resulted into `nil` being returned when there was no
  change in the attribute value.
- This commit corrects the behavior to return true if there is no change
  in attribute value. This is same as previous behavior of Rails 4.2
  plus benefit of no additional SQL call.
- Fixes #26593.

When the association is autosaved we were storing the details with
string keys. This was creating inconsistency with other details that are
added using the `Errors#add` method. It was also inconsistent with the
`Errors#messages` storage.

To fix this inconsistency we are always storing with symbols. This will
cause a small breaking change because in those cases the details could
be accessed as strings keys but now it can not.

The reason that we chose to do this breaking change is because `#details`
should be considered a low level object like `#messages` is.

Fix #26499.

[Rafael Mendonça França + Marcus Vieira]

Without this the changes to the lock version column will stick around
even after `touch` returns.

Before:

    model.touch
    model.changes
    # => {"lock_version"=>[0, "1"]}

After:

    model.touch
    model.changes
    # {}

* activerecord/mysql2: Avoid setting @connection to nil, just close it

Backport of https://github.com/rails/rails/pull/26434

* Add a CHANGELOG entry

I still think that this is something that should be handled in the pg
gem, but it's not going to end up happening there so we'll do it here
instead. Once we bump to pg 0.19 we can pass the encoding to the
`encode` method instead.

This issue occurs because C has no concept of encoding (or strings,
really). The bytes that we pass here when sending the value to the
database will always be interpreted as whatever encoding the connection
is currently configured to use. That means that roundtripping to the
database will lose no information

However, after assigning we round trip through our type system without
hitting the database. The only way that we can do the "correct" thin
here would be to actually give a reference to the connection to the
array type and have it check the current value of the connection's
encoding -- which I'm strongly opposed to. We could also pass in the
encoding when it's constructed, but since that can change independently
of the type I'm not a huge fan of that either.

This feels like a reasonable middle ground, where if we have an array of
strings we simply use the encoding of the string we're given.

Fixes #26326.

If a parent association was accessed in an `after_find` or
`after_initialize` callback, it would always end up loading the
association, and then immediately overwriting the association we just
loaded. If this occurred in a way that the parent's `current_scope` was
set to eager load the child, this would result in an infinite loop and
eventually overflow the stack.

For records that are created with `.new`, we have a mechanism to
perform an action before the callbacks are run. I've introduced the same
code path for records created with `instantiate`, and updated all code
which sets inverse instances on newly loaded associations to use this
block instead.

Fixes #26320.

Previously, if the the association was previously loaded and then
the foreign key changed by itself, a #save call would trigger a
load of the new associated record during autosave. This is unnecessary
and the autosave code (in that case) didn't use the loaded record
anyways.

Now the schema dumper by default doesn't align the types and arguments
in the ruby format anymore.

[Rafael Mendonça França + Robin Dupret]

Strict mode controls how MySQL handles invalid or missing values in
data-change statements such as INSERT or UPDATE. If strict mode is not
in effect, MySQL inserts adjusted values for invalid or missing values
and produces warnings.

```ruby
  def test_mysql_not_null_defaults_non_strict
    using_strict(false) do
      with_mysql_not_null_table do |klass|
        record = klass.new
        assert_nil record.non_null_integer
        assert_nil record.non_null_string
        assert_nil record.non_null_text
        assert_nil record.non_null_blob

        record.save!
        record.reload

        assert_equal 0,  record.non_null_integer
        assert_equal "", record.non_null_string
        assert_equal "", record.non_null_text
        assert_equal "", record.non_null_blob
      end
    end
  end
```

It is inconsistent with other types that only text/blob defaults treated
as an empty string. This commit fixes the inconsistency.