We have exactly this situation in our largest project, which mostly
uses its own MySQL database but has a couple of controllers that
synchronize data (with manual oversight) into an external Oracle
database.   That database is notorious for being unavailable at
inconvenient times.

Like you, our app runs fine without it, as long as you don't use the
three controllers that need to talk to the second DB (call it OtherDB
for the moment).   Our solution then was to build a module that can
detect the presence of OtherDB and then have all of our models that
access the second DB subclass an OtherDB::Base that looks like the
code below.

With this solution, the application will start without the other
database, and calls to the other database's methods won't break the
app.   In the controllers that need it, we set a before filter that
checks OtherDBPresence::present? and redirects back with a
flash[:error] to let the user know that those features are not
presently available.

# app/models/otherdb/
unless OtherDBPresence::present?
  class OtherDB::Base
    puts "*** Other DB is not present, so I'm loading the dummy
version of OtherDB::Base"
    def self.method_missing?(method_id, *argument)
      # eat all method calls
    end
  end

else
  class OtherDB::Base < ActiveRecord::Base
    use_db :prefix => "otherdb_"
    self.abstract_class = true

    #..lots of other stuff here to make our OtherDB classes work...

  end
end



-- 
SD Ruby mailing list
[email protected]
http://groups.google.com/group/sdruby

Reply via email to