You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
See the failing AR test case and output. I wasn't sure where the fix/test for this should live but I believe the test case is valid in terms of testing how remove_connection should undo what establish_connection does.
Expected behavior
klass2.remove_connection should remove any custom connection pool and allow the superclass's pool to be used by resetting caches/ivars indicating a custom pool is to be used.
Actual behavior
#24844's refactoring changed behavior when you configure a custom connection and remove it. Any subsequent calls to connection from that model will fail to find a pool and NOT fallback to the superclass' pool.
klass2.establish_connection(custom_config)# codeklass2.remove_connectionklass2.connection# raises ActiveRecord::ConnectionNotEstablished: No connection pool with id klass2 found
Workaround 1
klass2.establish_connection(custom_config)# codeklass2.remove_connectionklass2.connection_specification_name="primary"# this gets us back the primary poolklass2.connection
Workaround 2
klass2.establish_connection(custom_config)# codeklass2.remove_connectionklass2.establish_connection# this gets us back the primary poolklass2.connection
Neither of these changes were needed prior to #24844.
System configuration
Rails version: 5.0.0.rc1
Ruby version: 2.2.4
The text was updated successfully, but these errors were encountered:
remove_connection
When calling `remove_connection` on a model, we delete the pool so we also
need to reset the `connection_specification_name` so it will fallback to
the parent.
This was the current behavior before rails 5, which will fallback to the
parent connection pool.
[fixes#24959]
Special thanks to @jrafanie for working with me on this fix.
remove_connection
When calling `remove_connection` on a model, we delete the pool so we also
need to reset the `connection_specification_name` so it will fallback to
the parent.
This was the current behavior before rails 5, which will fallback to the
parent connection pool.
[fixes#24959]
Special thanks to @jrafanie for working with me on this fix.
jrafanie
added a commit
to jrafanie/manageiq
that referenced
this issue
May 13, 2016
Steps to reproduce
See the failing AR test case and output. I wasn't sure where the fix/test for this should live but I believe the test case is valid in terms of testing how
remove_connection
should undo whatestablish_connection
does.Expected behavior
klass2.remove_connection
should remove any custom connection pool and allow the superclass's pool to be used by resetting caches/ivars indicating a custom pool is to be used.Actual behavior
#24844's refactoring changed behavior when you configure a custom connection and remove it. Any subsequent calls to
connection
from that model will fail to find a pool and NOT fallback to the superclass' pool.Workaround 1
Workaround 2
Neither of these changes were needed prior to #24844.
System configuration
Rails version: 5.0.0.rc1
Ruby version: 2.2.4
The text was updated successfully, but these errors were encountered: