(Přesun mé odpovědi z používání PostgreSQL v paměti a její zobecnění):
Nemůžete spustit Pg in-process, in-memory
Nemohu přijít na to, jak spustit databázi Postgres v paměti pro testování. Je to možné?
Ne, to není možné. PostgreSQL je implementován v C a zkompilován do kódu platformy. Na rozdíl od H2 nebo Derby nemůžete jen načíst jar a zapálit ji jako vyhozenou DB v paměti.
Na rozdíl od SQLite, který je také napsán v C a zkompilován do kódu platformy, nelze PostgreSQL načíst ani v procesu. Vyžaduje více procesů (jeden na připojení), protože se jedná o architekturu s více procesy, nikoli s vícevlákny. Požadavek na vícenásobné zpracování znamená, že musíte spusťte správce pošty jako samostatný proces.
Místo toho:předkonfigurujte připojení
Navrhuji jednoduše napsat své testy tak, abyste očekávali, že konkrétní název hostitele/uživatelské jméno/heslo bude fungovat, a mít testovací svazek CREATE DATABASE vyřazenou databázi a poté DROP DATABASE na konci běhu. Získejte podrobnosti o připojení k databázi ze souboru vlastností, vlastností cíle sestavení, proměnné prostředí atd.
Je bezpečné používat existující instanci PostgreSQL, ve které již máte databáze, na kterých vám záleží, pokud uživatel, kterého zadáte do testů jednotek, není superuživatel, pouze uživatel s CREATEDB práv. V nejhorším případě vytvoříte problémy s výkonem v ostatních databázích. Z tohoto důvodu dávám přednost spuštění zcela izolované instalace PostgreSQL pro testování.
Místo toho:Spusťte k testování jednoúčelovou instanci PostgreSQL
Případně, pokud skutečně rádi byste mohli nechat svůj testovací svazek najít initdb a postgres binární soubory, spusťte initdb pro vytvoření databáze upravte pg_hba.conf trust , spusťte postgres chcete-li jej spustit na náhodném portu, vytvořte uživatele, vytvořte DB a spusťte testy. Můžete dokonce sbalit binární soubory PostgreSQL pro více architektur do jar a ty pro aktuální architekturu rozbalit do dočasného adresáře před spuštěním testů.
Osobně si myslím, že je to velká bolest, které je třeba se vyhnout; je mnohem snazší mít nastavenou testovací DB. S příchodem include_dir se to však trochu zjednodušilo podpora v postgresql.conf; nyní můžete pouze připojit jeden řádek a poté napsat vygenerovaný konfigurační soubor pro všechny ostatní.
Rychlejší testování s PostgreSQL
Další informace o tom, jak bezpečně zlepšit výkon PostgreSQL pro testovací účely, viz podrobná odpověď, kterou jsem na toto téma napsal dříve:Optimalizace PostgreSQL pro rychlé testování
H2 PostgreSQL dialekt není skutečnou náhradou
Někteří lidé místo toho používají ke spouštění testů databázi H2 v režimu dialektu PostgreSQL. Myslím, že je to skoro tak špatné jako lidé z Rails, kteří používají SQLite pro testování a PostgreSQL pro produkční nasazení.
H2 podporuje některá rozšíření PostgreSQL a emuluje dialekt PostgreSQL. Nicméně je to jen to - emulace. Najdete oblasti, kde H2 akceptuje dotaz, ale PostgreSQL ne, kde se chování liší atd. Najdete také spoustu míst, kde PostgreSQL podporuje dělat něco, co H2 prostě nemůže – jako funkce oken, v době psaní.
Pokud rozumíte omezením tohoto přístupu a váš přístup k databázi je jednoduchý, H2 může být v pořádku. Ale v tom případě jste pravděpodobně lepším kandidátem na ORM, který abstrahuje databázi, protože stejně nevyužíváte její zajímavé funkce – a v tom případě už se o kompatibilitu databáze nemusíte tolik starat.
Tabulkové prostory nejsou řešením!
Ne použijte tabulkový prostor k vytvoření databáze „v paměti“. Nejen, že je to zbytečné, protože to stejně výrazně nepomůže výkonu, ale je to také skvělý způsob, jak narušit přístup ke všem dalším, na kterých by vám mohlo záležet, ve stejné instalaci PostgreSQL. Dokumentace 9.4 nyní obsahuje následující varování:
UPOZORNĚNÍ
Přestože jsou tabulkové prostory umístěny mimo hlavní datový adresář PostgreSQL, jsou nedílnou součástí databázového clusteru a nelze je považovat za autonomní kolekci datových souborů. Jsou závislé na metadatech obsažených v hlavním datovém adresáři, a proto je nelze připojit k jinému databázovému clusteru nebo jednotlivě zálohovat. Podobně, pokud ztratíte tabulkový prostor (smazání souboru, selhání disku atd.), databázový cluster se může stát nečitelným nebo nefunkčním. Umístění tabulkového prostoru na dočasný souborový systém, jako je ramdisk, riskuje spolehlivost celého clusteru.
protože jsem si všiml, že to dělá příliš mnoho lidí a dostává se do problémů.
(Pokud jste to udělali, můžete mkdir chybějící adresář tablespace, aby se PostgreSQL znovu spustil, pak DROP chybějící databáze, tabulky atd. Je lepší to prostě nedělat.)