Vor einiger Zeit berichteten wir über eine Möglichkeit, Datenbank-Aktualisierungen auch unter JRuby einfach nach dem Deployment durchzuführen, indem man die Migration über den Browser anstößt.
Wir haben das nun schon eine Weile - auch produktiv - im Einsatz und sind sehr zufrieden damit. Es gibt aber einen Punkt, den man bei der Anwendungsentwicklung im Blick haben muss.
In einer unserer Anwendungen verwendeten wir ein Model State. Da es von diesem Model nur begrenzte Instanzen gab, wurden diese in einer Konstante gehalten:
  class State < ActiveRecord::Base
    
     OPEN   = State.find_by_name("open")
     CLOSED = State.find_by_name("closed")
     
     ...

  end

  state_open = State::OPEN
Das stellt zunächst kein Problem dar. Bis man die Anwendung in einer Produktionsumgebung laufen lässt. Die Zeile config.cache_classes = true in unserer Konfiguration sorgt nämlich dafür, dass alle Klassen beim Laden der Anwendung (und das ist bei JRuby das Laden der WAR-Datei) ausgelesen und gespeichert werden. Wenn nun die Klasse State ausgelesen wird, werden natürlich auch die Konstanten gesetzt. Und dafür wird ein Datenbank-Zugriff gemacht. Wenn also die Migration, die die Tabelle states anlegt, noch nicht gelaufen ist, schlägt bereits das Laden der Anwendung fehl - wodurch wir die Migration selbst gar nicht mehr ausführen können.

Die Vermeidung ist in unserem Beispiel einfach:
  class State < ActiveRecord::Base
    
     OPEN   = "open"
     CLOSED = "closed"

     def self.get_state name
       find_by_name(name)
     end
     
     def self.get_open
       get_state OPEN
     end

     ...

  end

  state_open = State.get_open()
Hier findet der Datenbankzugriff erst statt, wenn er wirklich benötigt wird.
In Rails 2.2 gibt es bestimmte Fälle, in denen das Problem auch ohne JRuby auftritt. Dort geht es allerdings um die Ausführung von rake-Tasks in Produktionsumgebungen. Diese Fehler sind aber mit Rails 2.3 behoben.

Quellen:
Artikel "Datenbankmigration im Browser"
Bugreport für Rails 2.2