H2 In-Memory Datenbank -> kann ich das irgendwie persistent speichern?

[hmm]

Hi Leute,

ich bau gerad wie Sau (reimt sich?) an der Software für meine Masterarbeit. Um die Daten zu speichern habe ich eine H2 Datenbank in mein Springprojekt eingebaut. Leider werden die Daten nur solange gespeichert wie das Programm läuft. Wenn ich neustarte sind alle Daten weg.

Gibt es einen soliden Weg Daten aus der H2 Datenbank peristent zu sichern, so dass sie nach Programmneustart noch da sind?

Ich habe mich für die H2 DB entschieden, weil ich diese DB in Spring einbetten kann und dadurch keine installation machen muss.

[pl]

hi,

Gibt es einen soliden Weg Daten aus der H2 Datenbank peristent zu sichern, so dass sie nach Programmneustart noch da sind?

Als JAR vielleicht?

Ich habe mich für die H2 DB entschieden, weil ich diese DB in Spring einbetten kann und dadurch keine installation machen muss.

Eine jar~Datei kann man bestimmt auch auf ner Festplatte speichern.

MfG

[marty]

Gibt es einen soliden Weg Daten aus der H2 Datenbank peristent zu sichern, so dass sie nach Programmneustart noch da sind?

Nein (stimmt nicht, geht mit SCRIPT TO, aber…), in-memory ist für „for example: rapid prototyping, testing, high performance operations, read-only databases“.

Nutze eine persistente H2-Datenbank.

[hmm]

hi,

das mit dem persistent speicher hat jetzt funktioniert.

ich musste einfach den relativen pfad ändern unter dem die daten gespeichert werden

[pl]

hi,

das mit dem persistent speicher hat jetzt funktioniert.

ich musste einfach den relativen pfad ändern unter dem die daten gespeichert werden

Interessant. Gab es eine relative Fehlermeldung wo dich darauf hingewisen hat oder sind deinem Programm was Du entwickelst die Pfade relativ egal?

MfG

[hmm]

ich habe das internet durchstöbert und habe gesehen das im file application.properties die zeile spring.datasource.url=jdbc:h2:~/test; geändert wurde zu spring.datasource.url=jdbc:h2:~/test;DB_CLOSE_ON_EXIT=FALSE

anscheint hat das gereicht damit das ganze zeugs gespeichert wird. bei zeiten (nach abgabe meiner masterarbeit) werde ich mich dazu genauer einlesen.

[pl]

Worauf ich hinauswollte ist das Thema Fehlerbehandlung. Und bei Dateien gibt es nicht nur Pfade sondern auch Berechtigungen. MfG

[hmm]

es gab keinen compile oder laufzeitfehler, dass teil war eine reine in-memory datenbank

oder meinst du etwas anderes?

[pl]

es gab keinen compile oder laufzeitfehler, dass teil war eine reine in-memory datenbank

Das ist schlecht.

oder meinst du etwas anderes?

Bring Deinen Code dazu daß er Fehlermeldungen ausgibt wenn Zugriffe auf Dateien fehlschlagen. Oder allgemeiner ausgedrückt: Den Layer der für die Persistierung zuständig ist.

.😉

[dedlfix]

Tach!

Bring Deinen Code dazu daß er Fehlermeldungen ausgibt wenn Zugriffe auf Dateien fehlschlagen. Oder allgemeiner ausgedrückt: Den Layer der für die Persistierung zuständig ist.

Du bist da auf dem falschen Dampfer unterwegs. Es ist kein Fehler sondern ein Feature von H2, dass man es persistierend und nicht-persistierend verwenden kann. Es ging hier lediglich darum, wie man dem H2 erzählt, gemäß welcher der beiden Formen es arbeiten soll.

dedlfix.

[pl]

Tach!

Bring Deinen Code dazu daß er Fehlermeldungen ausgibt wenn Zugriffe auf Dateien fehlschlagen. Oder allgemeiner ausgedrückt: Den Layer der für die Persistierung zuständig ist.

Du bist da auf dem falschen Dampfer unterwegs. Es ist kein Fehler sondern ein Feature von H2, dass man es persistierend und nicht-persistierend verwenden kann. Es ging hier lediglich darum, wie man dem H2 erzählt, gemäß welcher der beiden Formen es arbeiten soll.

Indem man nur einen gültigen Pfad einträgt? Und bei einem ungültigen Pfad wird nicht gespeichert? Das mag sein dass das ein Feature ist. Für mich ist das ein grottenhafter Stil!

MfG

[dedlfix]

Tach!

Es ist kein Fehler sondern ein Feature von H2, dass man es persistierend und nicht-persistierend verwenden kann. Es ging hier lediglich darum, wie man dem H2 erzählt, gemäß welcher der beiden Formen es arbeiten soll.

Indem man nur einen gültigen Pfad einträgt? Und bei einem ungültigen Pfad wird nicht gespeichert? Das mag sein dass das ein Feature ist. Für mich ist das ein grottenhafter Stil!

Du solltest vielleicht mit dem Bewerten von Dingen soweit warten, bis du deren Arbeitsweise verstanden hast. Soweit ich das sehe, handelt es sich nicht direkt um einen Pfad im Dateisystem, sondern um einen Connectionstring in Form einer URL, die noch ein paar weitere Parameter hat, um das Verhalten des Systems zu steuern. hmm musste da wohl nur bei diesen Parametern etwas ändern, um die gewünschte Arbeitsweise zu bekommen.

dedlfix.

[pl]

Tach!

Es ist kein Fehler sondern ein Feature von H2, dass man es persistierend und nicht-persistierend verwenden kann. Es ging hier lediglich darum, wie man dem H2 erzählt, gemäß welcher der beiden Formen es arbeiten soll.

Indem man nur einen gültigen Pfad einträgt? Und bei einem ungültigen Pfad wird nicht gespeichert? Das mag sein dass das ein Feature ist. Für mich ist das ein grottenhafter Stil!

Du solltest vielleicht mit dem Bewerten von Dingen soweit warten, bis du deren Arbeitsweise verstanden hast.

Siehe oben!

Soweit ich das sehe, handelt es sich nicht direkt um einen Pfad im Dateisystem, sondern um einen Connectionstring in Form einer URL, die noch ein paar weitere Parameter hat, um das Verhalten des Systems zu steuern. hmm musste da wohl nur bei diesen Parametern etwas ändern, um die gewünschte Arbeitsweise zu bekommen.

Genauso wurde das hier ja kommuniziert. Und genauso wie das hier kommuniziert wurde, macht es ja das Verhalten des Systems nicht besser. Und noch weniger den Stil. Auf Deutsch gesagt: Bekloppter gehts nicht.

MfG

[markk]

Moin ${vname},

es gab keinen compile oder laufzeitfehler, dass teil war eine reine in-memory datenbank Das ist schlecht.

Nein, das ist nicht schlecht, sondern das erwartete und dokumentierte Verhalten.

Bring Deinen Code dazu daß er Fehlermeldungen ausgibt wenn Zugriffe auf Dateien fehlschlagen.

Nein, das hat damit rein gar nichts zu tun.

Oder allgemeiner ausgedrückt: Den Layer der für die Persistierung zuständig ist.

Nein, das ist weder ein Permission-issue, noch ein "Layer"-Issue, noch ein Persistence-Issue, sondern das erwartete Verhalten.

Für mich ist das ein grottenhafter Stil!

Wenn ich ein ls ohne -al aurufe, erwarte ich auch nicht, dass ich User und Permissions sehe. Im Gegenteil. Eine IN-MEMORY-Datenbank, die sich beschwert, dass sie nicht gespeichert wird, ist per Definition keine in-mem-db.

Cheers, markk

[pl]

hmm,

Wenn ich ein ls ohne -al aurufe, erwarte ich auch nicht, dass ich User und Permissions sehe. Im Gegenteil. Eine IN-MEMORY-Datenbank, die sich beschwert, dass sie nicht gespeichert wird, ist per Definition keine in-mem-db.

Ein Code der falsche Pfadangaben ignoriert ist unsinnig. Und wenn bei einer richtigen Pfadangabe plötzlich gespeichert wird ist das in diesem Zusammenhang ein ziemlich bescheuertes Verhalten. Was würde denn der Code machen, wenn der Pfad richtig ist aber keine Berechtigung vorliegt?

MfG

[dedlfix]

Tach!

Ein Code der falsche Pfadangaben ignoriert ist unsinnig. Und wenn bei einer richtigen Pfadangabe plötzlich gespeichert wird ist das in diesem Zusammenhang ein ziemlich bescheuertes Verhalten.

Das war hier nicht der Fall. Der Fall hier war eine gültige Konfiguration, die aber nicht zum eigentlich gewünschten Verhalten führte. Der Pfad-Anteil war nur einer der Konfigurationswerte in diesem Connectionstring. Der war auch nicht das Problem, weil ein anderer Konfigurationswert angepasst werden musst, um das gewünschte Verhalten zu bekommen. Und es ist ziemlich normal und garantiert auch in deinen Programmen so, dass man A bekommt, wenn man A sagt und das ein gültiger Wert ist, auch wenn man eigentlich B meint.

dedlfix.

[pl]

Tach!

Ein Code der falsche Pfadangaben ignoriert ist unsinnig. Und wenn bei einer richtigen Pfadangabe plötzlich gespeichert wird ist das in diesem Zusammenhang ein ziemlich bescheuertes Verhalten.

Das war hier nicht der Fall.

Du verstehst das immer noch nicht: Ich finde das Verhalten bescheuert. Da heißt das ist meine ganz persönliche Ansicht zu diesem Thema.

Wenn ihr mit persönlichen Ansichten ein Problem habt ist das Eure Sache.

Und nein eine falsche Pfadangabe ist keine gültige Konfiguration.

MfG

[Matthias Apsel]

Hallo pl,

Du verstehst das immer noch nicht: Ich finde das Verhalten bescheuert. Da heißt das ist meine ganz persönliche Ansicht zu diesem Thema.

Dann schreib das in Zukunft immer deutlich dazu.

Wenn ihr mit persönlichen Ansichten ein Problem habt ist das Eure Sache.

Nicht, dass jemand noch auf die Idee kommt, du wolltest fachlich etwas beitragen.

Bis demnächst
Matthias

[pl]

Nicht, dass jemand noch auf die Idee kommt, du wolltest fachlich etwas beitragen.

Wie arrogant ist das denn schon wieder!?

Das kommentarlose Löschen meiner Beiträge übrigens auch!

MfG

[MudGuard]

Hi,

Du verstehst das immer noch nicht: Ich finde das Verhalten bescheuert.

Du selbst bist derjenige, der hier nicht versteht.

Und nein eine falsche Pfadangabe ist keine gültige Konfiguration.

Der Pfad war nicht falsch.

cu,
Andreas a/k/a MudGuard

[pl]

Hi,

Und nein eine falsche Pfadangabe ist keine gültige Konfiguration.

Der Pfad war nicht falsch.

Nachdem der relative Pfad geändert wurde, funktionierte die Persistierung.

Also ich denke, daß man gerade einem Anfänger erklären sollte, wie sich ein Programm bei einer falschen Pfadangabe zu verhalten hat. Oder allgemein, bei einem fehlgeschlagenen Zugriff auf das Dateisystem, neben dem Pfad spielt bekanntlich auch die Berechtigung eine Rolle.

So wie das Verhalten hier und da beschrieben wurde ist es schlecht.

Fassen wir das mal zusammen, geändert wurde:

spring.datasource.url=jdbc:h2:~/test;
  zu
spring.datasource.url=jdbc:h2:~/test;DB_CLOSE_ON_EXIT=FALSE

D.h., dass es für DB_CLOSE_ON_EXIT offensichtlich einen Default gibt der nicht explizit gesetzt werden muss. Daran sehen wir doch, daß ein solcher Default völlig unangebracht ist, weil er eben zur Pafdangabe dazugehört -- Und auch im CODE sichtbar dazugehören sollte.

Schlechter Stil! Nicht empfehlenswert!

Lösung: Auf den Default verzichten und eine Fehlermeldung ausgeben!

MfG

[dedlfix]

Tach!

Der Pfad war nicht falsch.

Nachdem der relative Pfad geändert wurde, funktionierte die Persistierung.

Auf einer Aussage, die mehr oder minder inkorrekt war, baust du nun deine ganze Argumentation auf? In einer Folgeantwort hat er doch gezeigt, was er geändert hat, und dabei handelte es sich um einen zusätzlichen Parameters. Der Pfad blieb dabei unverändert.

So wie das Verhalten hier beschrieben wurde ist es schlecht.

Das Verhalten wurde nur schlecht beschrieben.

dedlfix.

[MudGuard]

Hi,

Auf einer Aussage, die mehr oder minder inkorrekt war, baust du nun deine ganze Argumentation auf?

Natürlich, sonst müßte er ja zugeben, daß er falsch lag.

cu,
Andreas a/k/a MudGuard

[pl]

Hi

Wer länger hier ist, kann sich evntl. noch an eine Diskussion erinnern in der es darum ging, daß Content-Type: text/html; charset=UTF-8 zusammengehören damit ein Header vollständig ist.

Leider gibt es auch hier für den Parameter charset eine Default, so daß es anhand vom Code nicht ersichtlich ist warum das Verhalten nicht den Erwartungen entspricht wenn dieser Parameter fehlt.

Ich vertrat damals schon die Ansicht, daß ein Content-Type Header ohne diesen Parameter unvollständig ist. Und wie recht ich damit hatte, zeigt sich bis heute in immer noch unzähligen Anfragen eben zu diesem Thema und eben auch in diesem Forum.

Schönen Sonntag.

[pl]

hi

Auf einer Aussage, die mehr oder minder inkorrekt war, baust du nun deine ganze Argumentation auf? In einer Folgeantwort hat er doch gezeigt, was er geändert hat, und dabei handelte es sich um einen zusätzlichen Parameters. Der Pfad blieb dabei unverändert.

Nein, meine Aussage war nicht unkorrekt weil: Parameter und Pfadangabe untrennbar zusammengehören.

Im Übrigen hatten wir das Thema Default hier schon des Öfteren. Wobei Vielen gar nicht klar ist, für was ein Default steht, nämlich für einen fehlenden Wert. Und nicht etwa für Standard oder gar Standardverhalten!

Und gerade an diesem Punkt, wo es um die Persistierung geht, einen solchen Default zu setzen, ist eben schlecht, weil man das resultierende Verhalten nicht anhand des Codes sieht:

Im Code sieht man nämlich nur eine Pfadangabe und geht dann auch noch davon aus daß die vollständig ist und stimmt. Was de fakto eben nicht der Fall ist.

Ganz schlechter Stil!

MfG

[dedlfix]

Tach!

Auf einer Aussage, die mehr oder minder inkorrekt war, baust du nun deine ganze Argumentation auf?

Nein, meine Aussage war nicht unkorrekt weil: Parameter und Pfadangabe untrennbar zusammengehören.

Nicht deine Aussage, sondern die von hmm, dass es am Pfad liegen soll.

dedlfix.

[pl]

Es kommt darauf an, die eigentlichen Probleme zu erkennen und zu kommunizieren. MfG