Mam dość złożony projekt Django, który utrudnia/uniemożliwia używanie urządzeń do ładowania danych.Ładowanie dumpa SQL przed uruchomieniem testów Django
Chciałbym załadować zrzut bazy danych z produkcyjnego serwera bazy danych po tym, jak wszystkie tabele zostały utworzone przez testrunner i przed rozpoczęciem rzeczywistych testów.
Próbowałem różnych "magii" w MyTestCase.setUp(), ale bez powodzenia.
Wszelkie sugestie będą mile widziane. Dzięki.
Może zajść potrzeba zdefiniowania niestandardowego biegacza testowego. Jest tu trochę informacji: http://docs.djangoproject.com/en/dev/topics/testing/#using-different-testing-frameworks
Zasadniczo myślę, że można po prostu skopiować domyślny test runner z django.test.simple.run_tests, a następnie zmodyfikować go do własnych potrzeb.
Nie robiłem tego wcześniej, ale z mojego zrozumienia, że byłby to sposób na dostosowanie tego.
Lampy są najlepszym rozwiązaniem. Czy próbowałeś użyć ./manage.py dumpdata, aby utworzyć urządzenie z bieżącej bazy danych? Nie widziałem porażki na skomplikowanych modelach, ale myślę, że to możliwe.
Zakładając, że używasz mysql, powinieneś być w stanie napisać scenariusz za pomocą mysqldump.
Django obsługuje ładowanie plików SQL podczas wykonywania syncdb, reset, lub rozpoczęcie zawodnik testowy - ten robi dokładnie to, co można opisać:
http://docs.djangoproject.com/en/dev/howto/initial-data/#providing-initial-sql-data
Trzeba utworzyć katalog „sql” w swojej aplikacji katalogu, a następnie umieść plik o nazwie "mymodel.sql" w tym katalogu (gdzie "MyModel" jest odpowiednią nazwą modelu).
myproject/
|--myapp/
|--sql/
|--mymodel.sql
Możesz utworzyć ten SQL za pomocą narzędzi dump dla swojej bazy danych.
Po zakończeniu dumpingu należy zmodyfikować plik, aby usunąć wszystkie elementy poza odpowiednimi instrukcjami INSERT lub innymi skomplikowanymi elementami. W szczególności należy usunąć obsługę transakcji, tworzenie indeksu i tworzenie tabeli SQL, aby uniknąć błędów podczas ładowania duplikatów instrukcji tworzenia.
Używam tej metody do ładowania naprawdę dużych urządzeń - przetwarzanie jsona trwa zbyt długo, ale prosty import sql jest bardzo łatwy.
Należy pamiętać, że ta metoda załaduje sql dla dowolnego wywołania synchdb, zresetowania itp. Oprócz ładowania danych dla biegacza testowego - w ten sposób nie będzie można mieć różnych danych dla różnych przypadków testowych i musisz usunąć pliki przed zresetowaniem, jeśli nie chcesz, aby zostały załadowane z powrotem na serwer produkcyjny.
[1] http://www.sqlite.org/sqlite.html
[2] http://dev.mysql.com/doc/refman/5.1/en/mysqldump.html
[3] http://www.postgresql.org/docs/8.1/static/backup.html#BACKUP-DUMP
Od momentu opublikowania tej odpowiedzi to zachowanie stało się niedostępne w Django. Django 1.2 teraz ignoruje pliki 'sql' w katalogu' sql/'podczas uruchamiania frameworka testowego. –
Jeśli się nie mylę loading sql byłoby szybciej, ponieważ nie ma narzutu że terminarz wykonania. Szukam rozwiązania tego samego problemu. Mam duże DB do załadowania do testowania i chciałbym, aby ładowanie było szybkie. – Jeff
Używam szeroko relacji generycznych, co jest problemem podczas używania urządzeń. Wygląda na to, że zostało to właśnie rozwiązane w pracy nad 1.2, zobacz http://docs.djangoproject.com/en/dev/topics/serialization/#natural-keys – knutin
To wstyd, że możesz głosować tylko na komentarze, a nie na dół. Ten pierwszy komentarz po prostu cuchnie. – boatcoder