2010-08-09 15 views
15

Meine Integrationstests würden viel schneller laufen, wenn ich In-Memory-Datenbank statt PostgreSQL verwendete. Ich benutze JPA (Hibernate) und brauche eine In-Memory-Datenbank, die einfach auf JPA umgestellt werden kann, einfach einzurichten und zuverlässig ist. Es muss JPA und Hibernate (oder umgekehrt, wenn Sie so wollen) eher ausgiebig unterstützen, da ich keinen Wunsch habe, meinen Datenzugriffscode für Tests zu übernehmen.Einfach und zuverlässig in der Speicherdatenbank für schnelle Java-Integrationstests mit Unterstützung für JPA

Welche Datenbank ist die beste Wahl für die oben genannten Anforderungen?

Antwort

19

Für Integrationstest, verwende ich jetzt H2 (vom ursprünglichen Autor von HSQLDB), die ich über HSQLDB bevorzuge. Es ist faster (und ich möchte, dass meine Tests so schnell wie möglich sind), es hat einige nette Funktionen wie den compatibility Modus, das Entwicklerteam ist sehr reaktionsfähig (während HSQLDB jahrelang bis vor kurzem inaktiv war).

+0

Die Benchmarks sind für persistente Datenspeicherung, In-Memory-Ergebnisse möglicherweise unterschiedlich, da der größte Teil der Overhead aufgrund Disk/Cache-Richtlinien in den Datenbanken ist. Der Unterschied zwischen H2 und HSQLDB ist beträchtlich, aber nicht kritisch. Ich würde immer noch wählen basierend auf Benutzerfreundlichkeit, minimale Konfiguration, Funktionen. Und das Kompatibilitätsmodus-Feature sieht tatsächlich sehr attraktiv aus. Vielen Dank! – topchef

+0

@grigory: Ja, Sie haben Recht. Aber selbst wenn ein persistenter Modus verwendet wird, laufen H2 und HSQLDB standardmäßig im Speicher und verschieben das Schreiben auf die Festplatte (zum Preis von Durability). Die Daten sind also immer noch interessant. –

4

Ich habe HSQLDBin-memory für Integrationstest JPA/Hibernate Persistenz in Java verwendet. Startet ziemlich schnell, erfordert keine spezielle Einrichtung.

Das einzige Problem, das ich bisher mit der Verwendung von HSQLDB mit Hibernate gesehen habe, war mit der Stapelgröße zu tun, die auf 0 gesetzt werden muss, aber das könnte nur mit einer alten Version zusammenhängen. Ich werde graben und schauen, ob ich Details zu diesem Problem finden kann.

Derby supports an in-memory mode heutzutage ist es nicht mehr als experimentell markiert.

+0

gleiche Unterstützung für In-Memory-Datenbank Ich würde gerne die einfachste und am wenigsten invasive (hoffentlich Zero Customization (außer persistence.xml) -Lösung) haben. Vielen Dank! – topchef

+0

Eine weitere Abstimmung für HSQLDB, insbesondere seit der Veröffentlichung von V2, v1.x, würde einige der aktuellen Konstrukte, die von JDBC unterstützt werden, nicht mehr unterstützen, wie die Rückgabe von automatisch generierten Schlüsselwerten, aber v2 tut dies. – mezmo

2

Ich benutze Derby. Zum einen sind es ca. 3 Zeilen Code pro Unit-Test, da nach dem Test keine Abschaltung erforderlich ist. Sie müssen jedoch eine JPA-Implementierung verwenden, die Tabellen wie EclipseLink löschen und erstellen kann.

Derby kann auch eine neue In-Memory-Datenbank aus einer Datei initialisieren, so dass Sie eine Referenzdatenbank haben und jederzeit darauf zurückgreifen können.

Für Unit-Tests, obwohl ich lieber meine Objekte in der @Before-Logik meines Unit-Tests erstellen Ich finde es einfacher, vor allem mit JPA, da es mir die Flexibilität Refactorings zu tun und sich keine Sorgen über die zugrunde liegende Datenbankstruktur, andere Werkzeuge wie DBunit setzen praktisch auf eine statische Struktur und Refactoring bedeutet, dass die DBunit-XMLs manuell geändert werden müssen, anstatt sich auf die Refactoring-Funktionen von Eclipse zu verlassen.