Web2py – automatyczne tworzenie tabel systemowych w nowej aplikacji.

Web2py jest kompletnym frameworkem mieszczącym w sobie wiele poręcznych narzędzi ulokowanych w panelu administracyjnym. Znajduje się tam przede wszystkim, kreator aplikacji, który pozwala jednym kliknięciem stworzyć kompletną strukturę nowej aplikacji. Należy jednak pamiętać, że taka aplikacja będzie z definicji połączona z bazą SQLite. Jeśli tuż po utworzeniu, nie modyfikując ustawień aplikacji, uruchomimy ją zostanie wykonana automatyczna migracja tabel systemowych do tej bazy. W przypadku takiej surowej aplikacji są to tabele związane z autoryzacją u uwierzytelnieniem dołączane przez klasę Auth, której obiekt jest z definicji zainicjowany w nowej aplikacji.

web2py admin - tworzenie aplikacji

Migracja wykonywana jest dwuetapowo. Wpierw aplikacja tworzy serię plików z zapisem migracji poszczególnych tabel, a następnie wykonuje te migracje wykonując odpowiednie zapytania w bazie. Pliki migracji i sama baza SQLite znajdują się w katalogu aplikacji w podkatalogu databases

web2py katalog databases

Co zatem zrobić jeśli po uruchomieniu aplikacji i wywołaniu tym samym migracji zorientujemy się, że jednak chcemy by aplikacja współpracowała z inną bazą?
web2py plik db.py
Po pierwsze – trzeba skonfigurować w pliku db.py połączenie z odpowiednią bazą. Ja niestety muszę pracować w oparciu o bazy MSSQL więc pokażę przykładową konfigurację połączenia DAL z taką bazą (opis konfiguracji połączenia z innymi bazami można znaleźć w oficjalnej dokumentacji).

if not request.env.web2py_runtime_gae:
    db = DAL('mssql4n://username:password@localhost/nazwa_bazy')

Po ponownym uruchomieniu aplikacji migracje powinny się wykonać na nowej bazie. Jeśli jednak to nie nastąpi, może zachodzić konieczność usunięcia wszystkich plików z migracjami z katalogu databases tak, żeby wymusić ich ponowne stworzenie i migrację po kolejnych uruchomieniu aplikacji.

I to by było właściwie wszystko gdyby nie to, że pracując ostatnio nad aplikacją rozpoczętą przez kogoś innego, nie mogłam w żaden sposób wymusić migracji tabel systemowych, wymaganych przez klasę Scheduler (będę o tym narzędziu pisać niedługo). Winowajcą okazał się parametr połączenia z bazą fake_migrate_all ustawiony na wartość True, co powodowało, że migracje były jedynie fingowane. Tak więc należy na to też uważać przejmując po kimś aplikację lub kopiując z innej aplikacji konfigurację DAL.

Leave a Reply

%d bloggers like this: