Is the database huge? could you cache a copy of it? I'd think that having a separate database instance that is reliable and under your control which syncs data with the unreliable one would be the way to go. Baring that, I'm with Martin, instead of trying to degrade/unload models, make them active_resource models that point at a sinatra app. Then gracefully return empty data sets in the Sinatra app. The sinatra app would know when it has db connection failures and could alert you on those.
Rob On Fri, Apr 30, 2010 at 18:51, Vitaly Kushner <[email protected]> wrote: > Lets see if I understand your problem correctly. > You say your only problem is that the models that can't connect to the > db prevent the whole app from starting. > But if you move those models aside the app starts and works happily as > long as you don't touch > pages that use the said models. > > So.. my suggestion: prevent models from being loaded during the > startup and only load lazily. > > Rails in production tries to preload all models. The relevant code > segment from > > rails-2.3.5/lib/initializer.rb > > 407 # Eager load application classes > 408 def load_application_classes > 409 return if $rails_rake_task > 410 if configuration.cache_classes > 411 configuration.eager_load_paths.each do |load_path| > 412 matcher = /\A#{Regexp.escape(load_path)}(.*)\.rb\Z/ > 413 Dir.glob("#{load_path}/**/*.rb").sort.each do |file| > 414 require_dependency file.sub(matcher, '\1') > 415 end > 416 end > 417 end > 418 end > > I suppose you can turn off cache_classes which might be an acceptable > quick solution 'until the db comes back online' > or you can clear configuration.eager_load_paths > > > > On Apr 24, 2:39 am, Glenn Little <[email protected]> wrote: >> We've got an application that uses several databases. One of those >> databases is not in our control, and can go down occasionally. Several >> of our models rely on that database, so when it goes down our app is >> left unable to start. >> >> What we've done in the past when this happens is to just temporarily move >> the relevant model rb files out of the app source tree. The app then >> starts, and we then just have to stay away from any runtime code that >> hits those models (not a super-huge deal in this case, that code is >> relatively isolate). >> >> Is there a fairly clean way though to protect ourselves just via the >> code so that if that database goes offline we can perhaps warn ourselves >> and then continue running in a deprecated mode? >> >> Thanks... >> >> -glenn >> >> -- >> SD Ruby mailing list >> [email protected]http://groups.google.com/group/sdruby > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/group/sdruby -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
