connection_pool issue for arel_tables

[metalbot]

rails-sqlserver/activerecord-sqlserver-adapter#173

Summary: When using a model that has a base class that does an establish_connection to a database that is different from the default, the arel_table associated with that model is connected to the default database rather than the database to which it should be connected. This manifests itself in any manipulation of the arel table, for example by calling offset within the model.

This came up in an issue being discussed on the activerecord-sqlserver-adapter project (see link above).

To reproduce:

1. Create fresh rails project. Leave development database associated with sqlite.
2. Create an entry in database.yml for another database.
3. Create an abstract model that inherits from ActiveRecord::Base with a connection to the database in more cowbell #2.
4. Create a model that inherits from the abstract model, connecting to the alternative database.
5. In a rails console, examine the connection of the model's arel_table. For example:

Model.arel_table.engine.connection

This points at the sqlite connection that is the default.

We suspect that the problem may be related to ActiveRecord's arel_engine method (in base.rb or core.rb depending on your version). This method is trying to find the connection_pools by name. However, at some point these pools became no longer keyed by name, but rather by ActiveRecord::Base::ConnectionSpecification objects. This results in the connection being kicked up to the superclass repeatedly, ultimately landing on ActiveRecord::Base.

[ivanoats]

Good description, thanks! I created a test app in Rails 3.1.4 and it works fine, so this seems to be a regression.

[kennyj]

Hi ! @metalbot @ivanoats

I can reproduce this issue, and I think that I fixed this one.
Please review it :-)

BTW: relate to #4836 ?

[metalbot]

Nice. I can confirm that this resolves the problem.

[kennyj]

Thank you for confirmation :)
I'll send PR to master and 3-2-stable.

[metaskills]

Thanks @tenderlove, was almost sure this was an adapter bug at first. Took some digging. Please @kennyj or anyone, would love to see this make it's way to next 3-2-stable release. Hard to believe this was a regression. Guess I deal with multiple DBs to often too :)

[kennyj]

I'm closing this issue, because the above fix is merged.

Thanks.

[vishakhasawant]

Is this fixed for rails 3.1?

[carlosantoniodasilva]

@vishakhasawant it's unlikely, I see merges for master and 3-2. Moreover, 3.1 is only getting security fixes lately, I'd recommend migrating to 3-2 if possible.

[vishakhasawant]

@carlosantoniodasilva I have rails 3.2.0 version now but it seems it works if I add below lines to my model

@arel_table = Arel::Table.new(self.table_name, self)
@relation = ActiveRecord::Relation.new(self, @arel_table). 

Do I have to switch some minor version of rails 3.2?

[carlosantoniodasilva]

Apparently the merge commit exists on 3.2.3 forward:

$ g tag --contains 596ecf753eb87ee4f11fc87682b321c64b09d733
v3.2.3
v3.2.3.rc1
v3.2.3.rc2
v3.2.4
v3.2.4.rc1
v3.2.5
v3.2.6
v3.2.7
v3.2.7.rc1
v3.2.8
v3.2.8.rc1
v3.2.8.rc2
v3.2.9
v3.2.9.rc1
v3.2.9.rc2
v3.2.9.rc3

Best would be for you to be on the latest stable version always.

[vishakhasawant]

@carlosantoniodasilva Thanks a lot for your reply.

[carlosantoniodasilva]

No problem @vishakhasawant :)