Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Already on GitHub? Sign in to your account

HABTM: Assocations can be created in the wrong database #2189

christophersansone opened this Issue Jul 22, 2011 · 9 comments


None yet
7 participants

In has_and_belongs_to_many_association.rb, the insert_record() and delete_records() functions use Arel::Table.new() to build the records to insert and delete. The problem with the current implementation is that, no matter what, it will create the association in the default database, regardless of which database the association owner (@owner) is in. This will lead to the association record being in a different database than the owner record, which seems incorrect and unintended.

The resolution is simple: when Arel::Table.new() is called in insert_record() and delete_records(), the owner's arel engine should be passed in as the second parameter:

relation   = Arel::Table.new(@reflection.options[:join_table], @owner.class.arel_engine)

Since the owner's connection is used consistently throughout this unit, it seems to make sense that the owner's arel engine is used here as well.

In doing a quick search through the ActiveRecord code, it looks like the arel engine is specified almost every time Arel::Table.new() is called, so this seems like a straight-forward, correct, and consistent fix. There was one other method I noticed where this fix seems necessary as well: HasManyAssociation.delete_records().

Thank you very much!

@grzuy grzuy pushed a commit to grzuy/rails that referenced this issue Jul 23, 2011

@jonleighton @tenderlove jonleighton + tenderlove Test to verify that #2189 (count with has_many :through and a named_s…
…cope) is fixed

Just FYI, the commit by grzuy that is associated with this issue was actually associated with the ticket in the previous issue tracking system (lighthouse). As you can see, the timestamp of when I opened the ticket was many months after the commit was made.


@ghost ghost assigned jonleighton Jul 26, 2011

@jonleighton jonleighton added a commit to jeremy/rails that referenced this issue Sep 9, 2011

@jonleighton jonleighton Test to verify that #2189 (count with has_many :through and a named_s…
…cope) is fixed [#2189 state:resolved]

isaacsanders commented May 1, 2012

Is this still an issue @jonleighton?


schneems commented Sep 11, 2012

2 years since issue opened, 4 months since last ping by @isaacsanders, can we close this issue or is there more to be done?


steveklabnik commented Sep 11, 2012

I'm going to close it unless there's more (and by 'more,' I mean 'any') activity.

If someone still thinks this is a bug and/or wants to make a patch, feel free to re-open.

I have the same problem, I am using both PostgreSQL and SQL server connections and when I have a HABTM in the PostgreSQL database, I get faulty SQL because it uses the wrong database.

In my case the faults are for example:
ActiveRecord::StatementInvalid (PG::Error: ERROR: syntax error at or near "["
LINE 1: DELETE FROM [nova].[insight_group_insight_customer_number]

ActiveRecord::StatementInvalid (PG::Error: ERROR: relation "[insight_group_insight_customer_number]" does not exist
LINE 6: AND dep.refobjid = '"[insight_group_insight_cust...
(faulty []) and I get ActiveRecord::ConnectionAdapters::SQLServerAdapter in Arel::Table instead of ActiveRecord::ConnectionAdapters::PostgreSQLAdapter.

@join_table = Arel::Table.new(reflection.options[:join_table], owner.class.arel_engine)

similar to the solution above, or

@join_table = Arel::Table.new(reflection.options[:join_table], owner.class)

seems to solve the problem.

I probably should have mentioned that I am using rails 3.2.9 (activerecord 3.2.9) and arel 3.0.2.
Could this issue be reopened again?

@steveklabnik steveklabnik reopened this Nov 27, 2012


steveklabnik commented Jun 23, 2013

So, given the vast amount of inactivity on this overall issue, and how small this edge case is, I think I'm going to give this issue a close.

@MatsGard , it seems you have a work-around that works for you. If you can help me make a test case, I would consider writing a patch, but without a test, I'm too scared of breaking other people's stuff. So: if you (or anyone else) wants to get this fixed, please give me a test case using this model: http://edgeguides.rubyonrails.org/contributing_to_ruby_on_rails.html#create-a-self-contained-gist-for-active-record-issues

Thanks/Sorry :) / :(

Commenting so I can find this later in case I want to investigate.

MatsGard commented Jul 4, 2013

Ok, I tried to do a simplified test like the one you linked to, but I haven't yet managed to trigger the error on the join table described above, I will try to incorporate more code from the real application to see if that might cause the fault.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment