Ruby on Rails | Screencasts | Download | Documentation | Weblog | Community | Source

Ticket #6869 (new defect)

Opened 2 years ago

Last modified 1 year ago

Changeset 5753, partially reverting ActiveRecord::Base to 5660, breaks the multiple database connections pattern

Reported by: pico303 Assigned to: bitsweat
Priority: normal Milestone: 1.2.7
Component: ActiveRecord Version: edge
Severity: major Keywords:
Cc:

Description

We use multiple databases in our project. The wiki recommends the following:

class LegacyBase < ActiveRecord::Base
   self.abstract_class = true
   establish_connection "legacy_#{RAILS_ENV}" 
 end

class LegacyOrder < LegacyBase
   ...
end

class LegacyLineItem < LegacyBase
  ...
end

With update 5753, this no longer works. We have the following:

class Record < ActiveRecord::Base
     self.abstract_class = true
     establish_connection "opus_#{RAILS_ENV}"
end

When we try to access the classes that extend this, we now get:

  SQL (0.000000)   PGError: ERROR: relation "records" does not exist
: SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
 FROM pg_attribute a LEFT JOIN pg_attrdef d
 ON a.attrelid = d.adrelid AND a.attnum = d.adnum
 WHERE a.attrelid = 'records'::regclass
 AND a.attnum > 0 AND NOT a.attisdropped
 ORDER BY a.attnum



ActiveRecord::StatementInvalid (PGError: ERROR:  relation "records" does not exist
:             SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
              FROM pg_attribute a LEFT JOIN pg_attrdef d
                ON a.attrelid = d.adrelid AND a.attnum = d.adnum
             WHERE a.attrelid = 'records'::regclass
               AND a.attnum > 0 AND NOT a.attisdropped
             ORDER BY a.attnum

For us, 5753 creates more problems than it solved!

Change History

12/20/06 19:22:25 changed by pico303

Sorry, forgot the pound signs...

Changeset #5753 breaks multiple databases pattern. We prefer #5660.

12/20/06 19:24:38 changed by pico303

Damn! I meant [5753] and [5660]. Always get those links confused. Sorry.

(follow-up: ↓ 4 ) 12/20/06 20:11:40 changed by bitsweat

  • owner changed from core to bitsweat.
  • milestone changed from 1.x to 1.2.

[5753] just reverts [5660]. Did this work for you in 1.1.6? Or pre-[5660]?

(in reply to: ↑ 3 ) 12/22/06 18:25:00 changed by pico303

I don't know if this worked in 1.1.6; probably not. The project I've been working on was starting in the past month or so, so I've been on edge only to use the REST stuff, with the expectation of 1.2 releasing before my project deadline.

I checked the wiki history, and it looks like the tip I followed was posted May 5, 2006, so I guess it's worked at least that long. Don't know if that was edge or 1.1.6 though.

http://wiki.rubyonrails.com/rails/pages/HowtoUseMultipleDatabases/versions/29

(in reply to: ↑ description ) 12/26/06 18:53:19 changed by pico303

Would this change work, on line 819 of base.rb?

superclass == Base || superclass.abstract_class? || !columns_hash.include?(inheritance_column)

01/14/07 13:17:29 changed by manfred

This worked for me last week in Edge as far as I can recall. Have you defined 'opus_development', 'opus_test' and 'opus_production' in config/database.yml?

03/16/07 15:04:00 changed by salvaste

I can confirm this bug when using postgres and multiple db connections. This bug was not present in 1.1.6, but both 1.2.2 and 1.2.3 are affected.

06/26/07 02:05:55 changed by matt

I use:

class LegacyActiveRecord < ActiveRecord::Base
  self.abstract_class = true
end
class LegacyContent < LegacyActiveRecord
end

and finally

LegacyActiveRecord.establish_connection(ActiveRecord::Base.configurations['legacy'])

Everything works well for me with MySQL. Hopefully that helps.

08/14/07 22:19:22 changed by atduskgreg

I've been having this same problem using postgres. And pico303's change above seems to do the trick for me, though in the current version of rails it seems to be on line 905 of base.rb.

08/14/07 22:52:19 changed by atduskgreg

After a little more testing, I'm noticing that the change above, does not in fact consistently do the trick. I'm still seeing failed attempts to conduct queries against a table whose named is derived from the name of my abstract class and some slippage on relation methods as well (especially in rich chains, like: my_model.something_it_belongs_to.something_that_has_many_of.first will come up with a no method error on the second link of that chain). The behaviour I'm seeing is highly inconsistent (will work one minute, not the next, will work in script/console while not under mongrel, etc.). I'll try to get some harder evidence as to the proximate cause of the problem...