This patch
- reduces the duplication among the `reference`-family methods.
- better explains all the optians available for `add_reference`.
- redirects to user from `references` to `add_reference`.
Originated by #20184.
Active Record detects when the process has forked and automatically
creates a new connection pool to avoid sharing file descriptors.
If the existing connection pool had a schema cache associated with it,
the new pool should copy it to avoid unnecessarily querying the database
for its schema.
The code to detect that the process has forked is in ConnectionHandler,
but the existing test for it was in the ConnectionManagement test file.
I moved it to the right place while I was writing the new test for this
change.
Renamed `@reserved_connections` -> `@thread_cached_conns`. New name
clearly conveys the purpose of the cache, which is to speed-up
`#connection` method.
The new `@thread_cached_conns` now also uses `Thread` objects as keys
(instead of previously `Thread.current.object_id`).
Since there is no longer any synchronization around
`@thread_cached_conns`, `disconnect!` and `clear_reloadable_connections!`
methods now pre-emptively obtain ownership (via `checkout`) of all
existing connections, before modifying internal data structures.
A private method `release` has been renamed `thread_conn_uncache` to
clear-up its purpose.
Fixed some brittle `thread.status == "sleep"` tests (threads can go
into sleep even without locks).
I think we are better off leaving `sudo` outside of the documented
way of installing gems (`activerecord`, `actionpack`, …).
We don’t want newbies to think that `sudo` is required or, even worse, than
they actually have to type `[sudo] gem install`.
In most scenarios, `sudo` is not needed to install gems, and people who do
need it, probably already know about it.
What do you think? 😁
Stems from https://github.com/rails/rails/pull/20105#issuecomment-100900939
where @senny said:
> From my point of view, all the docs (guides, API) are version bound.
> They should describe that version and continue to be available when newer versions are released.
> The cross referencing can be done by the interested user.
If your STI class looks like this:
```ruby
class Company < ActiveRecord::Base
self.store_full_sti_class = false
class GoodCo < Company
end
class BadCo < Company
end
end
```
The expectation (which is valid) is that the `type` in the database is saved as
`GoodCo` or `BadCo`. However, another expectation should be that setting `type`
to `GoodCo` would correctly instantiate the object as a `Company::GoodCo`. That
second expectation is what this should fix.
