(Mijn antwoord verplaatsen van PostgreSQL in het geheugen gebruiken en het generaliseren):
Je kunt Pg in-process, in-memory niet uitvoeren
Ik kan er niet achter komen hoe ik de Postgres-database in het geheugen moet uitvoeren om te testen. Is het mogelijk?
Nee, het is niet mogelijk. PostgreSQL is geïmplementeerd in C en gecompileerd naar platformcode. In tegenstelling tot H2 of Derby kun je niet zomaar de jar . laden en start het op als een wegwerpbare in-memory DB.
In tegenstelling tot SQLite, dat ook in C is geschreven en naar platformcode is gecompileerd, kan PostgreSQL ook niet tijdens het proces worden geladen. Het vereist meerdere processen (één per verbinding) omdat het een multiprocessing, geen multithreading, architectuur is. De vereiste voor meerdere verwerkingen betekent dat u moet start de postmaster als een op zichzelf staand proces.
In plaats daarvan:configureer vooraf een verbinding
Ik raad aan om simpelweg je tests te schrijven om te verwachten dat een bepaalde hostnaam/gebruikersnaam/wachtwoord werkt, en het testharnas CREATE DATABASE te hebben. een wegwerpdatabase en vervolgens DROP DATABASE aan het einde van de rit. Haal de gegevens van de databaseverbinding op uit een eigenschappenbestand, bouw doeleigenschappen, omgevingsvariabele, enz.
Het is veilig om een bestaande PostgreSQL-instantie te gebruiken waarin u al databases heeft waar u om geeft, zolang de gebruiker die u aan uw unit-tests geeft niet is een superuser, alleen een gebruiker met CREATEDB rechten. In het slechtste geval creëer je prestatieproblemen in de andere databases. Om die reden geef ik er de voorkeur aan om een volledig geïsoleerde PostgreSQL-installatie uit te voeren om te testen.
In plaats daarvan:start een wegwerpbare PostgreSQL-instantie om te testen
Als alternatief, als je echt bent graag zou je je testharnas de initdb kunnen laten lokaliseren en postgres binaries, voer initdb uit om een database te maken, wijzigt u pg_hba.conf te trust , voer postgres uit om het op een willekeurige poort te starten, maak een gebruiker, maak een DB en voer de tests uit. Je zou zelfs de PostgreSQL-binaire bestanden voor meerdere architecturen in een pot kunnen bundelen en die voor de huidige architectuur uitpakken in een tijdelijke map voordat je de tests uitvoert.
Persoonlijk denk ik dat dat een grote pijn is die vermeden moet worden; het is veel gemakkelijker om gewoon een test-DB te configureren. Het is echter een beetje eenvoudiger geworden met de komst van include_dir ondersteuning in postgresql.conf; nu kun je slechts één regel toevoegen en dan een gegenereerd configuratiebestand voor de rest schrijven.
Sneller testen met PostgreSQL
Voor meer informatie over hoe u veilig verbeter de prestaties van PostgreSQL voor testdoeleinden, zie een gedetailleerd antwoord dat ik eerder over dit onderwerp schreef:PostgreSQL optimaliseren voor snel testen
H2's PostgreSQL-dialect is geen echte vervanging
Sommige mensen gebruiken in plaats daarvan de H2-database in PostgreSQL-dialectmodus om tests uit te voeren. Ik denk dat dat bijna net zo erg is als de mensen van Rails die SQLite gebruiken voor testen en PostgreSQL voor productie-implementatie.
H2 ondersteunt sommige PostgreSQL-extensies en emuleert het PostgreSQL-dialect. Het is echter niet meer dan dat:een emulatie. Je zult gebieden vinden waar H2 een zoekopdracht accepteert maar PostgreSQL niet, waar het gedrag verschilt, enz. Je zult ook tal van plaatsen vinden waar PostgreSQL iets ondersteunt dat H2 gewoon niet kan - zoals vensterfuncties, op het moment van schrijven.
Als u de beperkingen van deze aanpak begrijpt en uw databasetoegang eenvoudig is, is H2 mogelijk in orde. Maar in dat geval ben je waarschijnlijk een betere kandidaat voor een ORM die de database abstraheert omdat je de interessante functies toch niet gebruikt - en in dat geval hoef je je niet meer zo druk te maken over databasecompatibiliteit.
Tablespaces zijn niet het antwoord!
Doe niet gebruik een tabelruimte om een "in-memory" database te maken. Het is niet alleen onnodig omdat het de prestaties sowieso niet veel ten goede zal komen, maar het is ook een geweldige manier om de toegang tot alle anderen die u belangrijk vindt in dezelfde PostgreSQL-installatie te verstoren. De 9.4 documentatie bevat nu de volgende waarschuwing:
WAARSCHUWING
Hoewel ze zich buiten de hoofdmap van PostgreSQL-gegevens bevinden, vormen tabelruimten een integraal onderdeel van het databasecluster en kunnen ze niet worden behandeld als een autonome verzameling gegevensbestanden. Ze zijn afhankelijk van de metagegevens in de hoofdgegevensdirectory en kunnen daarom niet aan een ander databasecluster worden gekoppeld of afzonderlijk worden geback-upt. Het plaatsen van een tabelruimte op een tijdelijk bestandssysteem zoals een ramdisk brengt de betrouwbaarheid van het hele cluster in gevaar.
omdat ik merkte dat te veel mensen dit deden en in de problemen kwamen.
(Als je dit hebt gedaan, kun je mkdir de ontbrekende tablespace-map om PostgreSQL opnieuw te laten starten, en vervolgens DROP de ontbrekende databases, tabellen enz. Het is beter om het gewoon niet te doen.)