Uruchamianie PostgreSQL tylko w pamięci

Nie wiem, jak uruchomić bazę danych Postgres w pamięci do testowania. Czy to możliwe?

Nie, to niemożliwe. PostgreSQL jest zaimplementowany w C i skompilowany do kodu platformy. W przeciwieństwie do H2 czy Derby nie możesz po prostu załadować jar i odpal go jako jednorazową bazę danych w pamięci.

W przeciwieństwie do SQLite, który jest również napisany w C i skompilowany do kodu platformy, PostgreSQL nie może być również ładowany w procesie. Wymaga wielu procesów (jeden na połączenie), ponieważ jest to architektura wieloprocesowa, a nie wielowątkowa. Wymóg wieloprocesowości oznacza, że ​​musisz uruchom postmastera jako samodzielny proces.

Zamiast tego:wstępnie skonfiguruj połączenie

Proponuję po prostu napisać swoje testy, aby oczekiwały działania określonej nazwy hosta/nazwy użytkownika/hasła i mieć zestaw testowy CREATE DATABASE jednorazowa baza danych, a następnie DROP DATABASE pod koniec biegu. Uzyskaj szczegóły połączenia z bazą danych z pliku właściwości, właściwości celu kompilacji, zmiennej środowiskowej itp.

Bezpiecznie jest używać istniejącej instancji PostgreSQL, w której już masz bazy danych, na których Ci zależy, o ile użytkownik, którego podajesz do testów jednostkowych, nie superużytkownik, tylko użytkownik z CREATEDB prawa. W najgorszym przypadku stworzysz problemy z wydajnością w innych bazach danych. Z tego powodu wolę uruchomić całkowicie odizolowaną instalację PostgreSQL do testowania.

Zamiast tego:uruchom jednorazową instancję PostgreSQL do testowania

Ewentualnie, jeśli naprawdę chciałbyś, aby twoja wiązka testowa zlokalizowała initdb i postgres binaria, uruchom initdb aby utworzyć bazę danych, zmodyfikuj pg_hba.conf trust , uruchom postgres aby uruchomić go na losowym porcie, utwórz użytkownika, utwórz bazę danych i uruchom testy. Możesz nawet spakować pliki binarne PostgreSQL dla wielu architektur w słoiku i rozpakować te dla bieżącej architektury do katalogu tymczasowego przed uruchomieniem testów.

Osobiście uważam, że jest to poważny ból, którego należy unikać; o wiele łatwiej jest po prostu skonfigurować testową bazę danych. Jednak stało się to trochę łatwiejsze dzięki pojawieniu się include_dir wsparcie w postgresql.conf; teraz możesz po prostu dołączyć jedną linię, a następnie napisać wygenerowany plik konfiguracyjny dla całej reszty.

Szybsze testowanie z PostgreSQL

Więcej informacji o tym, jak bezpiecznie popraw wydajność PostgreSQL do celów testowych, zobacz szczegółową odpowiedź, którą napisałem na ten temat wcześniej:Zoptymalizuj PostgreSQL do szybkiego testowania

Dialekt PostgreSQL w H2 nie jest prawdziwym substytutem

Niektórzy zamiast tego używają bazy danych H2 w trybie dialektu PostgreSQL do przeprowadzania testów. Myślę, że to prawie tak samo źle, jak ludzie korzystający z Railsów używający SQLite do testowania i PostgreSQL do wdrażania produkcyjnego.

H2 obsługuje niektóre rozszerzenia PostgreSQL i emuluje dialekt PostgreSQL. Jednak to tylko emulacja. Znajdziesz obszary, w których H2 akceptuje zapytanie, ale PostgreSQL nie, gdzie zachowanie się różni, itp. Znajdziesz również wiele miejsc, w których PostgreSQL obsługuje robienie czegoś, czego H2 po prostu nie może - jak funkcje okien, w czasie pisanie.

Jeśli rozumiesz ograniczenia tego podejścia, a dostęp do bazy danych jest prosty, H2 może być OK. Ale w takim przypadku prawdopodobnie jesteś lepszym kandydatem na ORM, który abstrahuje bazę danych, ponieważ i tak nie korzystasz z jej interesujących funkcji – a w takim przypadku nie musisz już tak bardzo dbać o kompatybilność bazy danych.

Przestrzenie tabel nie są odpowiedzią!

Nie użyj obszaru tabel, aby utworzyć bazę danych „w pamięci”. Nie tylko jest to niepotrzebne, ponieważ i tak nie poprawi znacząco wydajności, ale jest to również świetny sposób na zakłócenie dostępu do innych elementów, na których ci zależy w tej samej instalacji PostgreSQL. Dokumentacja 9.4 zawiera teraz następujące ostrzeżenie: