PostgreSQL nur im Arbeitsspeicher ausführen

Ich kann nicht herausfinden, wie die In-Memory-Postgres-Datenbank zum Testen ausgeführt wird. Ist das möglich?

Nein, das ist nicht möglich. PostgreSQL ist in C implementiert und in Plattformcode kompiliert. Im Gegensatz zu H2 oder Derby können Sie nicht einfach das jar laden und starten Sie es als Wegwerf-In-Memory-DB.

Im Gegensatz zu SQLite, das ebenfalls in C geschrieben und in Plattformcode kompiliert wurde, kann PostgreSQL auch nicht im Prozess geladen werden. Es erfordert mehrere Prozesse (einen pro Verbindung), da es sich um eine Multiprocessing-, nicht um eine Multithreading-Architektur handelt. Die Multiprocessing-Anforderung bedeutet, dass Sie müssen Starten Sie den Postmaster als eigenständigen Prozess.

Stattdessen:Verbindung vorkonfigurieren

Ich schlage vor, einfach Ihre Tests zu schreiben, um zu erwarten, dass ein bestimmter Hostname/Benutzername/Passwort funktioniert, und die Testumgebung CREATE DATABASE zu verwenden eine Wegwerfdatenbank, dann DROP DATABASE am Ende des Laufs. Holen Sie sich die Datenbankverbindungsdetails aus einer Eigenschaftendatei, erstellen Sie Zieleigenschaften, Umgebungsvariable usw.

Es ist sicher, eine vorhandene PostgreSQL-Instanz zu verwenden, in der Sie bereits Datenbanken haben, die Ihnen wichtig sind, solange der Benutzer, den Sie für Ihre Komponententests angeben, nicht ist ein Superuser, nur ein Benutzer mit CREATEDB Rechte. Im schlimmsten Fall verursachen Sie Leistungsprobleme in den anderen Datenbanken. Aus diesem Grund ziehe ich es vor, eine vollständig isolierte PostgreSQL-Installation zum Testen auszuführen.

Stattdessen:Starten Sie eine Wegwerf-PostgreSQL-Instanz zum Testen

Alternativ, wenn Sie es wirklich sind Es wäre schön, wenn Ihr Testrahmen die initdb lokalisieren könnte und postgres Binärdateien, führen Sie initdb aus Um eine Datenbank zu erstellen, ändern Sie pg_hba.conf trust , führen Sie postgres aus Um es auf einem zufälligen Port zu starten, erstellen Sie einen Benutzer, erstellen Sie eine DB und führen Sie die Tests aus. Sie könnten sogar die PostgreSQL-Binärdateien für mehrere Architekturen in einem JAR bündeln und die für die aktuelle Architektur in ein temporäres Verzeichnis entpacken, bevor Sie die Tests ausführen.

Ich persönlich denke, dass dies ein großer Schmerz ist, der vermieden werden sollte; Es ist viel einfacher, nur eine Test-DB konfigurieren zu lassen. Mit dem Aufkommen von include_dir ist es jedoch etwas einfacher geworden Unterstützung in postgresql.conf; Jetzt können Sie nur eine Zeile anhängen und dann eine generierte Konfigurationsdatei für den Rest schreiben.

Schnelleres Testen mit PostgreSQL

Weitere Informationen zum sicheren Um die Leistung von PostgreSQL zu Testzwecken zu verbessern, lesen Sie eine ausführliche Antwort, die ich zuvor zu diesem Thema geschrieben habe:PostgreSQL für schnelles Testen optimieren

Der PostgreSQL-Dialekt von H2 ist kein echter Ersatz

Einige Leute verwenden stattdessen die H2-Datenbank im PostgreSQL-Dialektmodus, um Tests auszuführen. Ich denke, das ist fast so schlimm wie die Rails-Leute, die SQLite zum Testen und PostgreSQL für die Bereitstellung in der Produktion verwenden.

H2 unterstützt einige PostgreSQL-Erweiterungen und emuliert den PostgreSQL-Dialekt. Es ist jedoch genau das - eine Emulation. Sie werden Bereiche finden, in denen H2 eine Abfrage akzeptiert, PostgreSQL jedoch nicht, wo sich das Verhalten unterscheidet usw. Sie werden auch viele Stellen finden, an denen PostgreSQL etwas unterstützt, was H2 einfach nicht kann - wie Fensterfunktionen zur Zeit von schreiben.

Wenn Sie die Einschränkungen dieses Ansatzes verstehen und Ihr Datenbankzugriff einfach ist, ist H2 möglicherweise in Ordnung. Aber in diesem Fall sind Sie wahrscheinlich ein besserer Kandidat für ein ORM, das die Datenbank abstrahiert, weil Sie seine interessanten Funktionen sowieso nicht verwenden - und in diesem Fall müssen Sie sich nicht mehr so ​​​​viel um die Datenbankkompatibilität kümmern. P>

Tablespaces sind nicht die Antwort!

nicht Verwenden Sie einen Tablespace, um eine „In-Memory“-Datenbank zu erstellen. Es ist nicht nur unnötig, da es die Leistung sowieso nicht wesentlich verbessert, sondern es ist auch eine großartige Möglichkeit, den Zugriff auf alle anderen, die Ihnen wichtig sind, in derselben PostgreSQL-Installation zu unterbrechen. Die 9.4-Dokumentation enthält jetzt die folgende Warnung: