These are chat archives for ManageIQ/manageiq/rails5
remove_connectionis confusing. WHICH are we removing?
establish_connectioncreates a pool keyed by the class name
klass2.establish_connectionshould not use the new connection params?
remove_connectionremoves the connection pool keyed by the class name but does not reconnect the the "primary" pool
establish_connectionfixes it is because of the implicit
klass2.connection_specification_name = "primary"?
establish_connectioncreates a new pool with the class name and leaves the pool with the name "primary" around
So, is what we were doing before in with_remote_connection a valid use case for swapping the connection even if it's not threadsafe
We don't do those things in threads, so it should be fine
MiqRegionRemote.region_number_from_sequenceseems to be legit
remove_connectionis failing to allow the default "primary" pool to be used once you configure a custom pool
it is literally the opposite of establish_connection
In fact, you can feed the return from remove_connection directly into establish_connection
that is the api to hook up a connection to a model
That is a good point...is it?
is this a regression in rails or are we doing it wrong
remove_connectionaren't thread safe, so really shouldn't be used the way MIQ is using them — they're supposed to be ~once-off calls to tell the model how to connect
ensure) before anything else notices
remove_connectionisn't enough to get the model back to using whatever its ancestor does, is a bug
establish_connection, and going a level further down, to just make a connection without ever assigning it to a model
establish_connectionon that (to avoid the thread-safety issue with manipulating a shared class instance)
git grep ModelWithNoBackingTable), but those are transient, so I'm not too concerned, and that could probably still use