Closes #22584.

Look at `TestFixtures.set_fixture_class`. As documented, it
accepts a mapping of fixture identifiers (string or symbol) to Classes
(the model classes that implement the named fixture).

Look now at the initialization of `TestFixtures.fixture_class_names`.
It defines a Hash, which will return a string by default (where the
string is the estimated class name of the given fixture identifier).

Now look at TestFixtures.load_fixtures. It calls `FixtureSet.create_fixtures`,
passing in the mapping of `fixture_class_names`.

Following this on to `FixtureSet.create_fixtures`, this instantiates a
`FixtureSet::ClassCache`, passing in the map of class names.

`ClassCache`, in turn, calls `insert_class` for each value in the cache.
(Recall that `set_fixture_class` puts Class objects in there, while the
default proc for the mapping puts String objects.)

Look finally at `insert_class`. If the value is present, it checks to
see if the value is a subclass of `AR::Base`. Fair enough...but wait!
What if the value is a String? You get an exception, because a String
instance cannot be compared with a Class.

Judging from the implementation, it seems like the expected behavior
here is for `fixture_class_names` to have no default proc. Look-ups are
supposed to happen via `ClassCache`, with `fixture_class_names` existing
solely as a repository for explicitly-registered class mappings.

That is what this change does.

Currently, `set_fixture_class` is only available using the
`TestFixtures` concern and it is ignored for `rake db:fixtures:load`.
Using the correct model class, it is possible for the fixture load
to also load the associations from the YAML files (e.g., `:belongs_to`
and `:has_many`).

Closes #21201.

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.

In 1f006c an option was added called :class to allow passing anonymous
classes to association definitions. Since using :class instead of
:class_name is a fairly common typo even amongst experienced developers
this can result in hard to debug errors arising in raise_on_type_mismatch?

To fix this we're renaming the option from :class to :anonymous_class as
that is a more correct description of what the option is for. Since this
was an internal, undocumented option there is no need for a deprecation.

Fixes #19659

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.

- Add check for not deleting previously created fixtures, to overcome sti fixtures from multiple files
- Added fixtures and fixtures test to verify the same

- Fixed wrong fixtures duplicating data insertion in same table

 - Fixtures with non-string labels such as integers should be accessed
   using integer label as key. For eg. pirates(1) or pirates(42).
 - But this results in NotFound error because the label is converted into string before
   looking up into the fixtures hash.
 - After this commit, the label is converted into string only if its a
   symbol.
 - This issue was fount out while adding a test case for
   https://github.com/rails/rails/commit/7b910917.

Prior to this patch you'd end up with an error like:

```
ActiveRecord::RecordNotFound: Couldn't find <Model> with 'id'=<id> [WHERE (<default_scope condition>)]
```

`Computer` class needs to be require

See #17217 for more details

Rather than using the association's join_table method, which
constructs a table name from conventions, this should rely on the
through reflection's table_name to be resilient to tables that were
not automatically named.

fix fixtures not loading if a belongs_to association is defined with a :foreign_key option that's a symbol

Restore the 4.0 behaviour for 'sqlite3:///', but deprecate it. We'll
change to the absolute-path interpretation in 4.2.

The current "correct" spellings for in-memory, relative, and absolute
URLs, respectively, are:

    sqlite3::memory:
    sqlite3:relative/path
    sqlite3:/full/path

Substantially reverses/defers fbb79b51.
Uncovered by @guilleiguaran while investigating #14495, though that
sounds like a different issue.

Allows fixtures to use their $LABEL as part of a string instead
of limiting use to the entire value.

    mark:
      first_name: $LABEL
      username: $LABEL1973
      email: $LABEL@$LABELmail.com

    users(:mark).first_name # => mark
    users(:mark).username   # => mark1973
    users(:mark).email      # => mark@markmail.com

Fixes: #11524

Fix bad test order dependency between LoadAllFixturesTest#test_all_there and FoxyFixturesTest#test_ignores_belongs_to_symbols_if_association_and_foreign_key_are_named_the_same

Stubbing ENV[] is not safe outside MRI. At some point after the
stubbing has occurred a backtrace is printed to the ActiveSupport
warning log: there Rubinius accesses ENV['RBX_NOCOLOR'] to determine
if it should print the backtrace with colors or not, causing the
stub to fail. Other implementations might access ENV in a different
way too, we just can't predict it.
The only thing we can do here is to actually set the ENV with what
we want and restore it afterwards.

Allows you to change your configuration for calls to
`table_name_prefix`, `table_name_suffix`, and `pluralize_table_names`.
The default configuration is still ActiveRecord::Base, but you are now
able to change the configuration easily.

Also, constantizing the default_fixture_model_name when it gets loaded
in from the file. Later, when the class_name is passed to a new
FixtureSet, a deprecation warning will occur if the class_name is a
string.

As you can also configure your database connection using `ENV["DATABASE_URL"]`,
the fixture setup can't reply on the `.configurations` Hash.

As the fixtures are only loaded when ActiveRecord is actually used
(`rails/test_help.rb`) it should be safe to drop the check for an existing configuration.