| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
| |
Reported on #21509, how views is treated by `#tables` are differ
by each adapters. To fix this different behavior, after Rails 5.0
is released, deprecate `#tables`.
And `#table_exists?` would check both tables and views.
To make their behavior consistent with `#tables`, after Rails 5.0
is released, deprecate `#table_exists?`.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in `ConnectionPool#release` assumed that a single thread only
ever holds a single connection, and thus that releasing a connection
only requires the owning thread_id.
There is a trivial counterexample to this assumption: code that checks
out additional connections from the pool in the same thread. For
instance:
connection_1 = ActiveRecord::Base.connection
connection_2 = ActiveRecord::Base.connection_pool.checkout
ActiveRecord::Base.connection_pool.checkin(connection_2)
connection_3 = ActiveRecord::Base.connection
At this point, connection_1 has been removed from the
`@reserved_connections` hash, causing a NEW connection to be returned as
connection_3 and the loss of any tracking info on connection_1. As long
as the thread in this example lives, connection_1 will be inaccessible
and un-reapable. If this block of code runs more times than the size of
the connection pool in a single thread, every subsequent connection
attempt will timeout, as all of the available connections have been
leaked.
Reverts parts of 9e457a8654fa89fe329719f88ae3679aefb21e56 and
essentially all of 4367d2f05cbeda855820e25a08353d4b7b3457ac
|
| |
|
| |
|
|
|
|
|
|
|
|
| |
Follow-Up to https://github.com/rails/rails/pull/14348
Ensure that SQLCounter.clear_log is called after each test.
This is a step to prevent side effects when running tests. This will allow us to run them in random order.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
In the end I think the pain of implementing this seamlessly was not
worth the gain provided.
The intention was that it would allow plain ruby objects that might not
live in your main application to be subclassed and have persistence
mixed in. But I've decided that the benefit of doing that is not worth
the amount of complexity that the implementation introduced.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
#6441
An AR ConnectionSpec `wait_timeout` is pre-patch used for three
different things:
* mysql2 uses it for MySQL's own wait_timeout (how long MySQL
should allow an idle connection before closing it), and
defaults to 2592000 seconds.
* ConnectionPool uses it for "number of seconds to block and
wait for a connection before giving up and raising a timeout error",
default 5 seconds.
* ConnectionPool uses it for the Reaper, for deciding if a 'dead'
connection can be reaped. Default 5 seconds.
Previously, if you want to change these from defaults, you need
to change them all together. This is problematic _especially_
for the mysql2/ConnectionPool conflict, you will generally _not_
want them to be the same, as evidenced by their wildly different
defaults. This has caused real problems for people #6441 #2894
But as long as we're changing this, forcing renaming the
ConnectionPool key to be more specific, it made sense
to seperate the two ConnectionPool uses too -- these two
types of ConnectionPool timeouts ought to be able to be
changed independently, you won't neccesarily want them
to be the same, even though the defaults are (currently)
the same.
|
| |
|
| |
|
| |
|
|
|
|
| |
You can use multiple databases in your tests without disabling transactional fixtures.
|
| |
|
|
|
|
| |
RUNNING_UNIT_TESTS file for details, but essentially you can now configure things in test/config.yml. You can also run tests directly via the command line, e.g. ruby path/to/test.rb (no rake needed, uses default db connection from test/config.yml). This will help us fix the CI by enabling us to isolate the different Rails versions to different databases.
|
|
|
|
| |
configuration of the current connection at runtime
|
| |
|
| |
|
|
|
|
|
|
| |
[#4630 state:resolved]
Signed-off-by: José Valim <jose.valim@gmail.com>
|
| |
|
| |
|
| |
|
|
|
|
| |
Signed-off-by: Yehuda Katz <wycats@gmail.com>
|
|
|
|
|
|
| |
rollback a transaction
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
|
|
|
|
|
| |
connection only when needed [#1752 state:resolved]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
|
|
|
| |
Signed-off-by: David Heinemeier Hansson <david@loudthinking.com>
|
| |
|
|
|
|
| |
defined connections
|
|
|
|
|
|
| |
connections. [#936 state:resolved]
Signed-off-by: Pratik Naik <pratiknaik@gmail.com>
|
|
- also clean up some cruft remaining from per-thread connection cache
|