Esecuzione di PostgreSQL solo in memoria

Non riesco a capire come eseguire il database Postgres in memoria per il test. È possibile?

No, non è possibile. PostgreSQL è implementato in C e compilato nel codice della piattaforma. A differenza di H2 o Derby, non puoi semplicemente caricare il jar e avvialo come DB in memoria usa e getta.

A differenza di SQLite, anch'esso scritto in C e compilato nel codice della piattaforma, anche PostgreSQL non può essere caricato durante il processo. Richiede più processi (uno per connessione) perché è un'architettura multiprocessing, non multithreading. Il requisito di multielaborazione significa che devi avvia il postmaster come processo autonomo.

Invece:preconfigurare una connessione

Suggerisco semplicemente di scrivere i tuoi test per aspettarti che un particolare nome host/nome utente/password funzioni e avere il cablaggio di test CREATE DATABASE un database usa e getta, quindi DROP DATABASE alla fine della corsa. Ottieni i dettagli della connessione al database da un file delle proprietà, costruisci le proprietà di destinazione, una variabile di ambiente, ecc.

È sicuro utilizzare un'istanza PostgreSQL esistente in cui hai già database a cui tieni, purché l'utente che fornisci ai tuoi unit test non un superutente, solo un utente con CREATEDB diritti. Nel peggiore dei casi creerai problemi di prestazioni negli altri database. Per questo motivo preferisco eseguire un'installazione PostgreSQL completamente isolata per il test.

Invece:avvia un'istanza PostgreSQL usa e getta per il test

In alternativa, se sei davvero desideroso che tu possa avere il tuo cablaggio di prova individuare initdb e postgres binari, esegui initdb per creare un database, modificare pg_hba.conf a trust , esegui postgres per avviarlo su una porta casuale, creare un utente, creare un DB ed eseguire i test. Potresti persino raggruppare i binari di PostgreSQL per più architetture in un jar e decomprimere quelli per l'architettura corrente in una directory temporanea prima di eseguire i test.

Personalmente penso che sia un grande dolore che dovrebbe essere evitato; è molto più semplice configurare un DB di prova. Tuttavia, è diventato un po' più semplice con l'avvento di include_dir supporto in postgresql.conf; ora puoi semplicemente aggiungere una riga, quindi scrivere un file di configurazione generato per tutto il resto.

Test più rapidi con PostgreSQL

Per ulteriori informazioni su come sicuramente migliorare le prestazioni di PostgreSQL a scopo di test, vedere una risposta dettagliata che ho scritto su questo argomento in precedenza:Ottimizza PostgreSQL per test rapidi

Il dialetto PostgreSQL di H2 non è un vero sostituto

Alcune persone usano invece il database H2 in modalità dialetto PostgreSQL per eseguire i test. Penso che sia quasi quanto le persone di Rails che usano SQLite per i test e PostgreSQL per l'implementazione di produzione.

H2 supporta alcune estensioni PostgreSQL ed emula il dialetto PostgreSQL. Tuttavia, è solo questo:un'emulazione. Troverai aree in cui H2 accetta una query ma PostgreSQL no, dove il comportamento è diverso, ecc. Troverai anche molti posti in cui PostgreSQL supporta fare qualcosa che H2 non può proprio - come le funzioni della finestra, al momento di scrivendo.

Se comprendi i limiti di questo approccio e il tuo accesso al database è semplice, H2 potrebbe essere OK. Ma in tal caso probabilmente sei un candidato migliore per un ORM che astrae il database perché non stai comunque utilizzando le sue caratteristiche interessanti e, in tal caso, non devi più preoccuparti della compatibilità del database.

I tablespace non sono la risposta!

non utilizzare uno spazio tabella per creare un database "in memoria". Non solo non è necessario in quanto non aiuterà comunque le prestazioni in modo significativo, ma è anche un ottimo modo per interrompere l'accesso a qualsiasi altro che potrebbe interessarti nella stessa installazione di PostgreSQL. La documentazione 9.4 ora contiene il seguente avviso: