The combination of a :uniq => true association and the #distinct call
in #construct_limited_ids_condition combine to create invalid SQL, because
we're explicitly selecting DISTINCT, and also sending #distinct on to AREL,
via the relation#distinct_value.

Rather than build a select distinct clause in #construct_limited_ids_condition,
I set #distinct! and pass just the columns into the select statement.
This requires introducing a #columns_for_distinct method to return the
select columns but not the statement itself.

Suppose Man has_many interests, and inverse_of is used.

Man.first.interests.first.man will correctly execute two queries,
avoiding the need for a third query when Interest#man is called. This is
because CollectionAssociation#first calls set_inverse_instance.

However Man.first.interests.where("1=1").first.man will execute three
queries, even though this is obviously a subset of the records in the
association.

This is because calling where("1=1") spawns a new Relation object from
the CollectionProxy object, and the Relation has no knowledge of the
association, so it cannot set the inverse instance.

This commit solves the problem by making relations spawned from
CollectionProxies return a new Relation subclass called
AssociationRelation, which does know about associations. Records loaded
from this class will get the inverse instance set properly.

Fixes #5717.

Live commit from La Conf! ✨

In order to fix #10421 I need to enable merge to take an option
so that relations could be merged without making the last where
condition to win.

That fix would forever reside in 4-0-stable branch and would not be
merged to master since using scope without lambda has been deprecated.

In this commit I have extracted code into a method and I think it
makes code look better. Hence the request to merge it in both
master and 4-0-stable.

If there is any concern then this code can be merged only in
4-0-stable and that would be fine too.

the results. Added tests to check to make sure that inverse associations are
automatically found when has_many, has_one, or belongs_to associations
are defined.

This reverts commit 3043d45e, reversing
changes made to ca0275d3.

In #10410 it was noted that you can no longer create PK's with the
type of bigserial in PostgreSQL in 4.0.0.rc1. This is mostly
because the newer adapter is checking for column type with the
id column instead of just letting it pass through like it did
before.

Side effects:
You may just create a PK column of a type that you really don't
want to be your PK. As far as I can tell this was allowed in 3.2.X
and perhaps an exception should be raised if you try and do
something extremely dumb.

counter cache

At present, calling destroy multiple times on the same record results
in the belongs_to counter cache being decremented multiple times. With
this change the record is checked for whether it is already destroyed
prior to decrementing the counter cache.

Fixing CHANGLOG description

Remove extra line.

Remove blank lines.

fixes #10419

Following code should raise  IrreversibleMigration. But the code was
failing since options is an array and not a hash.

def change
  change_table :users do |t|
    t.remove_index [:name, :email]
  end
end

Fix was to check if the options is a Hash before operating on it.

For one-to-one nested associations, if you build the new (in-memory)
child object yourself before assignment, then the NestedAttributes
module will not overwrite it, e.g.:

    class Member < ActiveRecord::Base
      has_one :avatar
      accepts_nested_attributes_for :avatar

      def avatar
        super || build_avatar(width: 200)
      end
    end

    member = Member.new
    member.avatar_attributes = {icon: 'sad'}
    member.avatar.width # => 200

It is new in PostgreSQL-9.2 .

fixes bug introduced by  #3329
These are the conditions necessary to reproduce the bug:
- For an association, autosave => true.
- An association record is being destroyed
- A new association record is being created.
- There is a unique index one of the association's fields.
- The record being created has the same value as the record being
destroyed on the indexed field.

Before, the deletion of records was postponed until after all
insertions/saves.  Therefore the new record with the identical value in
the indexed field caused a non-unique value error to be thrown at the database
level.

With this fix, the deletions happen first, before the insertions/saves.
Therefore the record with the duplicate value is gone from the database
before the new record is created, thereby avoiding the non-uniuqe value
error.

Introduced in 09ac1776.

When using symbol keys, ActiveRecord will now translate aliased attribute names to the actual column name used in the database:

With the model

  class Topic
    alias_attribute :heading, :title
  end

The call

  Topic.where(heading: 'The First Topic')

should yield the same result as

  Topic.where(title: 'The First Topic')

This also applies to ActiveRecord::Relation::Calculations calls such as `Model.sum(:aliased)` and `Model.pluck(:aliased)`.

This will not work with SQL fragment strings like `Model.sum('DISTINCT aliased')`.

Github #7839

*Godfrey Chan*

without this, it's not possible to use UUID primary keys without uuid-ossp installed and activated

activerecord/lib/active_record/associations.rb states:

    # [association=(associate)]
    #   Assigns the associate object, extracts the primary key, sets it as the foreign key,
    #   and saves the associate object.

Since commit 42dd5d9f to fix #7191, this
is no longer the case if the associate has changed, but is the same
object. For example:

    # Pirate has_one :ship
    pirate = Pirate.create!(catchphrase: "A Pirate")
    ship = pirate.build_ship(name: 'old name')
    ship.save!

    ship.name = 'new name'
    pirate.ship = ship

That last line should trigger a save. Although we are not changing the
association, the associate (ship) has changed.

It's simpler to assume that passed env is just a string without any
extensions, especially when DatabaseTasks are intended to be used also
without rails.

This is a public class, which could be used directly in order to allow
easier database management. Now it also contains settings, which will be
used by databases.rake.