Czy mogę ustawić tory, aby używać mysql z MEMORY jako silnikiem DB? Nigdy nie restartuję mysql i odbudowuję db tak często, że wolałbym, żeby był szybki. Posiadanie bazy pamięci dla uruchomionych testów też byłoby miłe.Szyny z bazą pamięci
EDYTOWANIE: Powinienem określić, że jest to tylko dla dev/testing, a nie dla produkcji.
Nie rozumiem, dlaczego nie mogłeś; Twój wybór silnika pamięci masowej to szczegół implementacji MySQL. Wszystko, co powinieneś zrobić, to ustawić :options => "ENGINE=MEMORY" w swojej deklaracji utworzenia create_table w swoich migracjach.
Oczywiście nie rozumiem też, dlaczego będzie - zwłaszcza w produkcji. Dokumentacja MySQL dla silnika MEMORY to full of caveats, podobnie jak przydzielanie pól o ustalonej długości, a uzyskany przyrost prędkości musi być trywialny w porównaniu do ryzyka utraty wszystkiego. Jeśli twoja aplikacja jest taka, że nic nie musi zostać utrwalone, dlaczego, dlaczego nie po prostu całkowicie pominąć ActiveRecord i warstwować swoje modele na Memcached?
Używam sqlite3 w bazie danych pamięci do testowania. Zwykle jest trochę szybszy niż plik, ale nie tak bardzo, chyba że masz masę danych testowych.
Aby ustawić swój database.yml że będzie wyglądać następująco:
test:
adapter: sqlite3
database: ":memory:"
Będziesz mieć również załadować do swojego schematu w bazie testowej w pamięci pomocnika tak:
config = YAML::load(IO.read(File.dirname(__FILE__) + "/../config/database.yml"))
ActiveRecord::Base.logger = Logger.new(File.dirname(__FILE__) + "/../log/debug.log")
ActiveRecord::Base.establish_connection(config["test"])
load(File.dirname(__FILE__) + "/../db/schema.rb")
Dlaczego konieczne jest ustanowienie połączenia w teście? Myślałem, że to coś, co Rails mógłby zrobić dla ciebie. –
Zrobiłem to również i to jest słodkie, ale przestałem używać SQLite lokalnie z powodu różnic między nim a MySQL/PostgreSQL. ActiveRecord ukrywa większość szczegółów, ale jest dość różnicy, aby było irytujące. –
Połączenie musi zostać nawiązane przed uruchomieniem testów, aby schemat mógł zostać załadowany do bazy danych pamięci przed załadowaniem szyn. Jedyne znane mi miejsce do załadowania jest w pomocniku testowym iw tym momencie nie ma połączenia z bazą danych za pomocą szyn. Proszę mnie poprawić, jeśli się mylę, lub jeśli jest łatwiejszy sposób to zrobić. –
Do celów testowych rozważ wtyczkę https://github.com/mvz/memory_test_fix. To wykorzystanie tak proste jak zaktualizować database.yml i uruchomić
rails plugin install git://github.com/mvz/memory_test_fix.git
Możesz spróbować również zainstalować memory_test_fix gem, ale to z innej gałęzi git i nie obsługuje Rails 3.
Klejnot pomógł mi zredukować testu czas wykonania przypadków od 25 sekund do 19. Z drugiej strony wprowadza 2-sekundowy narzut inicjalizacji schematu bazy danych (i nie mam ich zbyt wiele). Tak więc w przypadku małych zestawów testów nie warto się tym przejmować.
Rozwiązanie z odpowiedzi Jason Stewart jest w zasadzie takie samo. I użyłem go zamiast wtyczki, ponieważ łatwiej było połączyć go z wtyczką Spork.
Powiedziałbym, że pierwotnie, ale to NIE jest do produkcji, tylko do mnie rozwija. Umieszczenie silnika w migracji nie jest wtedy opcją (chyba, że warunkowo robię to w oparciu o środowisko). –
To też warunkowo oparte na środowisku. Dlaczego to nie jest opcja? ': options => (RAILS_ENV! = 'production'?" ENGINE = MEMORY ": nil)' (Tylko upewnij się, że twoje testy nie są odrzucane przez jakąś dziwność, która istnieje tylko w silniku pamięci.Osobiście nadal nie zawracałbym sobie tym głowy; ale jeśli naprawdę sądzisz, że szybkość bazy danych jest twoją wąską gardłem testowania, zrób to sam.) – SFEley
Ponieważ nie chcę angażować migracji w SCM z tymi wszystkimi bzdurami. Chciałem po prostu zrobić to lokalnie, w moim własnym małym świecie, i gdyby to było trochę szybsze dla mnie, gdy musiałem zrobić odbudowę bazy danych lub coś podobnego, to wygrać, ale jeśli nie, kogo to obchodzi, po prostu użyłbym regularna konfiguracja. Z odpowiedzi i innych lektur wynika, że jest to więcej pracy niż jej (potencjalnie nawet nie). –