Since we have been using this `Arel::Table` since 111ccc83,
in order to properly handle queries, it's important that we properly type cast arguments.

Make name of attribute medium instead of normal

The current code base is not uniform. After some discussion,
we have chosen to go with double quotes by default.

Fixes #25892.

This fixes incorrect assumptions made by e991c7b8 that we can assume the
DB is already casting the value for us. The enum type needs additional
information to perform casting, and needs a subtype.

I've opted not to call `super` in `cast`, as we have a known set of
types which we accept there, and the subtype likely doesn't accept them
(symbol -> integer doesn't make sense)

Close #23190

As described in the "Follow Coding Conventions" section in our
contribution guide (http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#follow-the-coding-conventions)
we favor `assert_not` over `refute`.

While we don't usually make stylistic changes on it's own I opted to do
it in this case. The reason being that test cases are usually copied as
a starting point for new tests. This results in a spread of `refute` in
files that have been using it already.

After 908cfef6 was introduced fixtures that did not set an enum would
return nil instead of the default enum value.

The fixtures should assume the default if a different enum is not
defined.

The change checks first if the enum is defined in the fixture before
setting it based on the fixture.

Fixes #17511 and #17415

Currently, values for columns backing Active Record enums must be
specified as integers in test fixtures:

    awdr:
      title: "Agile Web Development with Rails"
      status: 2

    rfr:
      title: "Ruby for Rails"
      status: <%= Book.statuses[:proposed] %>

This is potentially confusing, since enum values are typically
specified as symbols or strings in application code. To resolve the
confusion, this change permits the use of symbols or strings to specify
enum values:

    awdr:
      status: :published

It is compatible with fixtures that specify enum values as integers.

The testing of error messages have been implemented wrongly a few times.
This is an attempt to fix it.

For example, some of these test should have failed with the new code.
The reason they are not failling with the new string is the fact they
were not being tested beforehand.

...so it doesn't look like you *have* to use SQL strings for that case (not
anymore!). Would like to replace the SQL string example with something that
you cannot do with the "normal" query API, but I could not come up with a
short, realistic example. Suggestions welcome!

Using enum names in SQL strings doesn't actually work, the test was wrong (fixed
in 3dfd1bab).

Make sure we have coverage for both the find/build cases

Also updated the documentation about the new ability to query them normally,
and added test to make sure they work!

In addition to cleaning up the implementation, this allows type casting
behavior to be applied consistently everywhere. (#where for example). A
good example of this was the previous need for handling value to key
conversion in the setter, because the number had to be passed to `where`
directly. This is no longer required, since we can just pass the string
along to where. (It's left around for backwards compat)

Fixes #18387

Added a few more methods on Module/Class to the dangerous class methods
blacklist. (Technically, allocate and new are already protected currently because
we happen to redefine them in the current implantation.)

Closes #16792

The original attempt didn't really fix the problem and wasn't testing the
problematic area. This commit corrected those issues in the original commit.

Also removed the private `enum_mapping_for` method. As `defined_enums` is now a
method, this method doesn't provide much value anymore.

Add tests to make sure scopes cannot be create with names such as:
private, protected, public.
Make sure enum values don't collide with those methods too.

This fixes a bug where any enum attribute of a model
would be evaluated always as 0 when calling the
database on validations.

This fix converts the value of the enum attribute
to its integer value rather than the string before
building the relation as the bug occured when the
string finally gets converted to integer using
string.to_i which converts it to 0.

[Vilius Luneckas, Ahmed AbouElhamayed]

Dangerous name conflicts includes instance or class method conflicts
with methods defined within `ActiveRecord::Base` but not its ancestors,
as well as conflicts with methods generated by other enums on the same
class.

Fixes #13389.

To make this possible we have to override the save_changed_attribute
hook.

Example:

    class Conversation < ActiveRecord::Base
      enum status: [ :active, :archived ]
    end

Before:

    Conversation::STATUS # => { "active" => 0, "archived" => 1 }

After:

    Conversation.statuses # => { "active" => 0, "archived" => 1 }

Closes #13650, #13672

This is an alternate implementation to solve #13650. Currently form fields
contain the enum value (eg. "1"). This breaks because the setter `enum=`
expects the label (eg. "active").

ActiveRecord::Enum allows you to use labels in your application but store numbers.
We should make sure that all parts after AR are dealing with labels and not the
underlying mapping to a number.

This patch defines `_before_type_cast` on every enum column to return the label.
This method is later used to fetch the value to display in form fields.

I deliberately copied the implementation of the enum getter instead of delegating to it.
This allows you to overwrite the getter and for example return a `Value Object` but have it
still work for form fields.

Previously, this would give an `ArgumentError`:

   class Issue < ActiveRecord::Base
     enum :status, [:open, :finished]
   end

   Issue.open.build # => ArgumentError: '0' is not a valid status
   Issue.open.create # => ArgumentError: '0' is not a valid status

PR #13542 muted the error, but the issue remains. This commit fixes
the issue by allowing the enum value to be written directly via the
setter:

   Issue.new.status = 0 # This now sets status to :open

Assigning a value directly via the setter like this is not part of the
documented public API, so users should not rely on this behavior.

Closes #13530.

Previously, the writer methods would simply check whether the passed
argument was the symbol representing the integer value of an enum field.
Therefore, it was not possible to specify the numeric value itself but
the dynamically defined scopes generate where clauses relying on this
kind of values so a chained call to a method like `find_or_initialize_by`
would trigger an `ArgumentError`.

Reference #13530

This allows to assign both `String` and `Symbol` values to the enum
without having to call `to_sym`, which is a security problem.