2011-05-05 9 views
9

Mam proces w tle, który modyfikuje rekordy w bazie danych. Modele łączą się z bazą danych za pomocą następujących informacji:Autonomiczny ruby ​​- jak załadować różne środowiska z database.yml

dbconfig = YAML::load(File.open('database.yml')) 
ActiveRecord::Base.establish_connection(dbconfig["development"]) 
class Clcar < ActiveRecord::Base 
.... 
end 

Wszystkie klasy modeli mają te wiersze u góry.

Zgadzam się, że to zły sposób robienia tego.

  1. Czy istnieje lepszy sposób na uzyskanie połączenia z klasą modelu? Jak przekazać połączenie do modelu?
  2. Chcę móc uruchomić mój proces w tle w innym środowisku, na przykład "produkcja".

Jak to osiągnąć?

+3

Użyj 'YAML.load_file' zamiast' load' i 'File.open'. –

Odpowiedz

25

Skonfiguruję połączenie raz na początku procesu w tle. Po nawiązaniu połączenia raz, wszystkie modele i tak będą działać poprawnie.

Połączenie kod zakład będzie wyglądać mniej więcej tak:

@environment = ENV['RACK_ENV'] || 'development' 
@dbconfig = YAML.load(File.read('config/database.yml')) 
ActiveRecord::Base.establish_connection @dbconfig[@environment] 
+0

Zdecydowanie rozwiązuje jeden problem. Ale w jaki sposób prowadziłbyś różne środowiska, np. Produkcję, rozwój? Dzięki – truthSeekr

+1

ustawiam te same zmienne środowiskowe w moich skryptach w tle jako moje główne środowisko. Tak więc uruchamiam moje polecenie w tle za pomocą 'RACK_ENV = production ruby ​​run_stats_updater.rb', a wewnątrz mojego kodu używam' @environment = ENV ['RACK_ENV'] || "rozwój" w celu określenia, które środowisko należy zastosować. –

4

polecam patrząc w użyciu rails runner.

Skrypty runner mają dostęp do wszystkiego, łącznie z bazą danych, ale bez wszystkich widoków z modelu MVC. Doskonale nadają się do zadań back-end lub zadań, które działają w bazie danych, ale nie mają żadnego interfejsu.

Można również użyć rails rake zamiast tego, ale uważam, że zadania rake są ukierunkowane na utrzymanie plików i katalogów oraz na strukturę budynku, a skrypty runner lepiej dla zwykłych zadań, takich jak coś, co można uruchamiać z crona okresowo.

Mam taki, którego używam do pobierania dzienników z witryny, analizowania ich, a następnie wprowadzania ich do jednej z moich baz danych. Nie ma powodu, aby uruchamiać pracę jako część aplikacji Rails, ponieważ nie było potrzeby korzystania z interfejsu. Uruchamianie jako skrypt runner dobrze pasuje.

Wbudowany help mówi:

 
Usage: runner [options] ('Some.ruby(code)' or a filename) 

    -e, --environment=name   Specifies the environment for the runner to operate under (test/development/production). 
            Default: development 

    -h, --help      Show this help message. 

You can also use runner as a shebang line for your scripts like this: 
------------------------------------------------------------- 
#!/path/to/your/rails/app/script/rails runner 

Product.find(:all).each { |p| p.price *= 2 ; p.save! } 
------------------------------------------------------------- 

Ta ostatnia linia:

Product.find(:all).each { |p| p.price *= 2 ; p.save! } 

pokazuje, jak łatwo jest.

+0

To wygląda na poręczne, ale przyciągnęłoby cały stos szyn, co spowodowałoby nadejście procesu. Mogę jednak spojrzeć na to, żeby użyć go do niektórych z nieczęsto uruchamianych skryptów, dzięki. –

+0

Jeśli wszystko, czego potrzeba, to ActiveRecord i być może Active_Support, to naprawdę łatwo załadować je bezpośrednio bez reszty stosu Railsów. Ja też to zrobiłem.ActiveRecord sprawdzanie struktury bazy danych i budowanie modeli jest prawdopodobnie najwolniejszą częścią używania skryptu biegacza, więc trudno uniknąć początkowej pauzy. –

Powiązane problemy