Jak zarządzać migracjami dla silnika szynowego + atrapa aplikacji

Question

Właśnie dołączyłem do projektu rozwijającego silnik szyny, który ma również atrapę do testowania.

foo/ 
foo/spec/dummy/ 

Są identyczne migracje w

foo/db/migrate/ 
foo/spec/dummy/db/migrate/ 

Gdybym rake db:migrate z manekina aplikacji, wszystko jest dobrze. Jeśli zrobię to samo z silnika (bieżący katalog = foo), pojawi się błąd dotyczący wielu migracji o tej samej nazwie.

Q1) Czy pliki Rakefiles zostały zranione? (powinno być db:migrate rekursywnie w dół do fałszywej aplikacji?)

Q2) Czy migracje powinny odbywać się tylko w jednym katalogu? Jeśli tak, to jaki?

Używamy Rails 3.2.9, rubin 1.9.3p194.

Answer 1

Pytanie 1
Rakefile powinny mieć wpis w celu uwzględnienia spec/manekina aplikacji. Na przykład,

Bundler::GemHelper.install_tasks 
APP_RAKEFILE = File.expand_path("../spec/dummy/Rakefile", __FILE__) 
load 'rails/tasks/engine.rake' 

Oto bardziej szczegółowy przykład Rakefile, https://github.com/twinge/questionnaire_engine/blob/engine2/Rakefile

Pytanie 2
IMO, migracje powinny istnieć tylko na foo/db/migrować folderu, a nie foo/spec/dummy/db/migrate. W rzeczywistości nie kontroluję wersji atrybutu db/migrate lub db/schema.

Dlaczego? Korzystam z fałszywej aplikacji, upewniając się, że pełna instalacja mojego silnika działa w 100%. Dlatego też, gdybym w wersji kontrolował stan foo/spec/dummy db, testowałbym tak, jakby była poprzednia instalacja.

Przykład silnika
https://github.com/twinge/questionnaire_engine/tree/engine2