diff options
author | eileencodes <eileencodes@gmail.com> | 2019-07-30 16:56:32 -0400 |
---|---|---|
committer | eileencodes <eileencodes@gmail.com> | 2019-08-02 15:22:11 -0400 |
commit | bfec23aecb71b351b84e4c4592494f68f4d47be2 (patch) | |
tree | 5708bc4bd286582c4597aa1db745fba7690acd50 /guides/rails_guides/generator.rb | |
parent | 1c7207a22faca3f07ee9aee1dc00a5b01286de2f (diff) | |
download | rails-bfec23aecb71b351b84e4c4592494f68f4d47be2.tar.gz rails-bfec23aecb71b351b84e4c4592494f68f4d47be2.tar.bz2 rails-bfec23aecb71b351b84e4c4592494f68f4d47be2.zip |
Fix `PG::ConnectionBad` error when running fixtures
At first this appeared to be a multi-db bug but after some invesitgation
it was clear that this can occur just by calling `establish_connection`
from ApplicationRecord.
After some investigation we found that this only occurred when using
fixtures. The console boots fine, the server runs fine, and the tests
even run fine if we used paralellization or eager loading in the tests.
I tracked the issue down to the line that calls
`self.connection_specification_name = name` in the SchemaMigration
changes for Rails 6.0. But how can this be? That is not that major of a
change? How could `connection_specification_name` be a problem?
First `connection_specification_name` caches the name of the connection
specificatio. Second, fixtures were incorrectly holding onto a reference
to that connection.
So when you went to run the tests the models wouldn't be connected and
when the fixtures tried to load the data it would choke on that
unconnected database.
The changes here move the connection into a lambda so we can call it
when we need it rather than blowing up before the model is connected.
Fixes #36743
Co-authored-by: Aaron Patterson <aaron.patterson@gmail.com>
Diffstat (limited to 'guides/rails_guides/generator.rb')
0 files changed, 0 insertions, 0 deletions