(Flytter mit svar fra Brug af PostgreSQL i hukommelsen og generaliserer det):
Du kan ikke køre Pg in-process, in-memory
Jeg kan ikke finde ud af, hvordan jeg kører Postgres-databasen i hukommelsen til test. Er det muligt?
Nej, det er ikke muligt. PostgreSQL er implementeret i C og kompileret til platformskode. I modsætning til H2 eller Derby kan du ikke bare indlæse jar og fyr den op som en kasserbar DB i hukommelsen.
I modsætning til SQLite, som også er skrevet i C og kompileret til platformskode, kan PostgreSQL heller ikke indlæses under processen. Det kræver flere processer (en pr. forbindelse), fordi det er en multiprocessing, ikke en multithreading, arkitektur. Multiprocessing-kravet betyder, at du skal start postmasteren som en selvstændig proces.
I stedet:Forkonfigurer en forbindelse
Jeg foreslår, at du blot skriver dine tests for at forvente, at et bestemt værtsnavn/brugernavn/adgangskode virker, og at du har testudstyret CREATE DATABASE en engangsdatabase, derefter DROP DATABASE i slutningen af løbeturen. Få databaseforbindelsesdetaljerne fra en egenskabsfil, byg målegenskaber, miljøvariable osv.
Det er sikkert at bruge en eksisterende PostgreSQL-instans, som du allerede har databaser, du holder af i, så længe den bruger, du leverer til dine enhedstest, er ikke en superbruger, kun en bruger med CREATEDB rettigheder. I værste fald vil du skabe præstationsproblemer i de andre databaser. Jeg foretrækker at køre en fuldstændig isoleret PostgreSQL-installation til test af den grund.
I stedet:Start en bortskaffet PostgreSQL-instans til test
Alternativt, hvis du virkelig er ivrig kan du få din testsele til at finde initdb og postgres binære filer, kør initdb for at oprette en database skal du ændre pg_hba.conf at trust , kør postgres for at starte den på en tilfældig port, skal du oprette en bruger, oprette en DB og køre testene. Du kan endda samle PostgreSQL binære filer til flere arkitekturer i en krukke og pakke dem til den aktuelle arkitektur ud til en midlertidig mappe, før du kører testene.
Personligt synes jeg, det er en stor smerte, som bør undgås; det er meget nemmere bare at have en test-DB konfigureret. Det er dog blevet lidt nemmere med fremkomsten af include_dir understøttelse i postgresql.conf; nu kan du bare tilføje en linje, og derefter skrive en genereret konfigurationsfil for resten.
Hurtigere test med PostgreSQL
For mere information om, hvordan du sikkert forbedre ydelsen af PostgreSQL til testformål, se et detaljeret svar, jeg skrev om dette emne tidligere:Optimer PostgreSQL til hurtig test
H2's PostgreSQL-dialekt er ikke en sand erstatning
Nogle mennesker bruger i stedet H2-databasen i PostgreSQL-dialekttilstand til at køre tests. Jeg tror, det er næsten lige så slemt som Rails-folkene, der bruger SQLite til test og PostgreSQL til produktionsimplementering.
H2 understøtter nogle PostgreSQL-udvidelser og emulerer PostgreSQL-dialekten. Det er dog bare det - en emulering. Du vil finde områder, hvor H2 accepterer en forespørgsel, men PostgreSQL ikke gør det, hvor adfærd adskiller sig osv. Du vil også finde masser af steder, hvor PostgreSQL understøtter at gøre noget, som H2 bare ikke kan - som vinduesfunktioner, på tidspunktet for skriver.
Hvis du forstår begrænsningerne ved denne tilgang, og din databaseadgang er enkel, kan H2 være OK. Men i så fald er du sandsynligvis en bedre kandidat til en ORM, der abstraherer databasen, fordi du alligevel ikke bruger dens interessante funktioner - og i så fald behøver du ikke bekymre dig så meget om databasekompatibilitet længere.
Tablespaces er ikke svaret!
Gør ikke bruge et tablespace til at oprette en "in-memory"-database. Ikke alene er det unødvendigt, da det alligevel ikke vil hjælpe på ydeevnen væsentligt, men det er også en fantastisk måde at forstyrre adgangen til andre, du måske interesserer dig for i den samme PostgreSQL-installation. 9.4-dokumentationen indeholder nu følgende advarsel:
ADVARSEL
Selvom de er placeret uden for PostgreSQL-databiblioteket, er tablespaces en integreret del af databaseklyngen og kan ikke behandles som en selvstændig samling af datafiler. De er afhængige af metadata indeholdt i hoveddatabiblioteket og kan derfor ikke knyttes til en anden databaseklynge eller sikkerhedskopieres individuelt. Hvis du mister et tablespace (sletning af fil, diskfejl osv.), kan databaseklyngen blive ulæselig eller ude af stand. At placere et tablespace på et midlertidigt filsystem som en ramdisk risikerer pålideligheden af hele klyngen.
fordi jeg bemærkede, at for mange mennesker gjorde dette og løb ind i problemer.
(Hvis du har gjort dette, kan du mkdir det manglende tablespace-bibliotek for at få PostgreSQL til at starte igen, derefter DROP de manglende databaser, tabeller osv. Det er bedre bare ikke at gøre det.)