JPA exportieren

B

beta20

Top Contributor
Hallo zusammen,

ich habe einige JPA Tabellen mit entsprechenden Attributen.
Also z.B.
Entity: Auto
Attribute: Farbe etc.

Nun möchte ich aber eine sog. Backup - Funktion programmieren.
Das heißt ich möchte meine ganze DB exportieren, wobei ich auch selektieren möchte, welche JPA Tabellen alles exportiert werden sollen.
Nachdem dies exportiert wurde, wird eine Datei erstellt.

Nun soll es aber auch die Möglichkeit geben, den Export wieder importieren, sodass alle Daten wieder verfügbar sind.

Nun:
1. Wie mache ich das?
2. Welche Dateiendung hat der Export? .xml ?
3. Ich möchte nur eine Datei, nicht für jede Entity eine Datei

Über jede Hilfe freue ich mich
 
B

beta20

Top Contributor
Das Backup soll aber auch für "normale" User gemacht werden können, die keinen Zugang direkt auf die DB haben.
Welche Möglichkeiten gibt es hierzu?
Ich nutze JPA / Hibernate
 
K

kneitzel

Gast
Also normale User nutzen ja normalerweise eine Applikation. Diese lädt Daten aus der Datenbank über ein DataLayer (wie auch immer das aufgebaut ist) und nutzt dann normalerweise Business Objekte. Diese kannst Du natürlich wie jedes andere Objekt auch behandeln, d.h. die Möglichkeiten der Serialisierung (Egal ob Binary oder XML) sind hier auch anwendbar.
Oder gerne auch die Nutzung lokaler Datenbanken - das ist alles Deiner Fantasie überlassen - die Techniken sind dabei aber eigentlich immer relativ primitiv und gehören eben zu den Grundlagen der Entwicklung (egal ob Java, .Net oder irgend eine andere Sprache).

Wichtig ist dabei aber, dass man sauber trennt um so die Komplexität gering zu halten. Ich neige so gerne dazu, "Plain old (java) objects" zu nutzen (POJO). Das bedeutet, dass Du ganz einfache Objekte hast, die Du dann beliebig nutzen kannst. Aber klar - gewisse Dingen mögen da direkt rein gehören wie die typischen Kandidaten zur Erstellung eines Strings oder die Berechnung des Hashcodes.

Durch die Trennung ist es dann aber relativ unkompliziert, hier verschiedene DataSources zu haben. (Hier kann dann sogar Dependency Injection ins Spiel kommen - so dass es Dir als Entwickler egal ist, woher die Daten kommen und dass kann der Admin selbst konfigurieren wenn er möchte. Aber das geht dann jetzt hier deutlich zu weit denke ich mal.)

Also mein Hauptpunkt, um den es mir hier geht wäre "Separation of Concerns" - also die Trennung von Anliegen.

Konrad
 
B

beta20

Top Contributor
Genau - ich habe Pojos, die ich vorhalte und die dann wiederum via JPA / Hibernate in meine DB gespeichert werden.
Nun möchte realisieren, dass alle Pojos quasi herunterladen werden können.
Also im Prinzip will ich eine Export / Import - Funktion programmieren.

Ich denke ein Pojo nach XML zu konvertieren sollte nicht all zu schwer sein.
Was ich jedoch mich dann Frage, wie ein Fremdschlüssel gespeichert wird.
Also bspw. Pojo: Auto 1...n Reifen
Wie wird dann die AutoId bei Reifen gespeichert?

Was ich jedoch noch besser fände:
Die Exportdatei zu verschlüsseln (Binär-Datei???) -> sodass der Enduser nicht alle Felder so einfach auslesen kann. In der DB werden ja auch applikationsspezifische Informationen gespeichert, die der User nicht so einfach sehen soll.
Wie kann ich so etwas realisieren? Was würde sich hierfür anbieten? In welchem Dateityp kann man das speichern?

Danke für jede Hilfe
 
K

kneitzel

Gast
Also der User sollte nur Daten herunter laden können, die er auch sehen kann. Importieren kann er nur Daten, die er auch schreiben kann. Damit ist dann eine Verschlüsselung unnötig. Generell wirst du hier große Probleme haben, denn die Applikation läuft unter dem User und wenn die Applikation sowohl Ent- als auch Verschlüsseln kann, dann kann das der User auch. Wirkliche Security wirst Du da nicht bekommen. Daher kannst Du gerne etwas Security versuchen, aber jede Mühe ist das schon fast zuviel und zum anderen erschwerst Du den möglichen Support.

Was der User speichert ist nie ein komplettes Backup (Es sei denn, er hat auf alle Daten Zugriff).

So Du die Ids nur bei Dir vergibst, so können dies ganz normale autoincrement Werte sein. Die Id wird dann halt gespeichert. Sobald Du Ids an mehreren Stellen vergeben können willst ist die normale Lösung die Verwendung von GUIDs. Oder habe ich Dich da jetzt missverstanden? Was für Probleme siehst Du? Das EInfügen einer festen ID in einer Datenbank? MS SQL macht dies nicht - es sei denn man erlaubt es explizit einmal über einen Befehl. Solche Besonderheiten muss man dann natürlich mit implementieren oder ggf. die Ids einlesen um dann beim Insert die IDs gezielt zu ändern. (Sprich bei neuen Inserts gibt es eine neue ID, die dann entsprechend verwendet wird.

Bezüglich speichern der Datei(en) - ich finde die Lösung ganz interessant, dass die Formate eigentlich ZIP Files sind. Also Endung kannst Du Dir selbst aussuchen aber dennoch ist es eigentlich ein ZIP File. Macht alles etwas kompakter und Du kannst ggf. auch "mehrere Dateien speichern".

Konrad
 
B

beta20

Top Contributor
Nein, der User soll quasi ein komplettes BackUp machen können, inkl. den Daten, die er nicht sehen darf.
Die Anwendung läuft auf dem Server vom User selbst.
Da nicht jeder aber DB-Kenntnisse hat (und ich auch nicht möchte, dass der User sich in die DB anmeldet) möchte ich eben eine Backup bzw. auch wieder Import - Funktion programmieren.

Gut was man machen könnte:
Das Backup als eine Datei speichern (eig. eine ZIP-Datei).
Die Datei-Endung wird jedoch beim Speichern geändert, also z.B. "meineDatei.abc".
Die ZIP-Datei könnte man noch mit einem Passwort verschlüsseln. Das Passwort habe natürlich nur ich.
Somit kann ich gewähren, dass man nicht einfach an alle Daten der DB rankommt.

Beim Import wird die Datei dann eben wieder eingelesen - das Passwort ist eben hart in der Anwendung (also String) hinterlegt.
Wäre das eine Möglichkeit bzw. ist das möglich? Dass man dies sicherlich auch hacken kann, ist mir bewusst - aber es ist auf jeden Fall schon Mal schwieriger.

Zu der Frage mit den ID´s der Fremdschlüssel
Speichere ich dann die ID der Fremdschlüssel einfach so ab?
So zum Beispiel die ID=2 von der Entity "Reifen".

<auto>
<reifen_fk>2</reifen_fk/>
<auto>

Danke für jede Hilfe.
 

Aktuelle Jobs

Neue Themen


Oben