MySQL Path bekommen

[beta20]

Hallo zusammen,

wie schaffe ich es aus einer Webapplikation (Wilfly nutze ich als Applikationsserver) heraus den Pfad des verwendeten MySql zu bekommen.
Also was ich benötige ist: "/C:/Program Files/MySQL/MySQL Server 5.7/bin/";
Da aber der Pfad immer unterschiedlich sein kann, möchte ich diesen gerne ermitteln.

Danke für jede Hilfe

 

[Thallius]

Wozu brauchst du den?

 

[beta20]

Um ein Import / Export auszuführen:

        String username = "test";
        String password = "test";
        String databaseName = "testDB";
String mySQLpath = "/C:/Program Files/MySQL/MySQL Server 5.7/bin/";

        Process p = null;
        Runtime runtime = Runtime.getRuntime();

        p = runtime.exec(mySQLpath + "mysqldump -u " + username + " -p"
                + password + " -B " + databaseName + " -r "
                + import.sql);

 

[Thallius]

Wie wäre es das einfach mit einem query zu machen statt mit externen programmen?

 

[Tobse]

@TE:

Ich glaube du verwechselst hier etwas. Es gibt einmal den MySQL-Server, auf welchem eine DB läuft. Und es gibt das Tool mysqldump. Die beiden sind 100% voneinander unabhängig. Angenommen der Server läuft auf 192.168.0.100:3600 dann kannst du mit einer bei dir lokal installierten Version von mysqldump einen Dump erstellen:

mysqldump -u user -p passwort -h 192.168.0.100 out.sql

Wenn das nicht dein Ziel ist musst du nochmal näher beschreiben wie deine Umgebung aufgebaut ist und von welchem Rechner aus welche Datenbank wohin gedumped werden soll.

@Thallius: mysqldump macht genau das: es führt mysql queries gegen die DB aus und schreibt sie als ausführbares SQL in eine Datei.

 

[Thallius]

@TE:

@Thallius: mysqldump macht genau das: es führt mysql queries gegen die DB aus und schreibt sie als ausführbares SQL in eine Datei.

Das ist mir schon klar. Ich benutze es ja auch ständig. Nur glaube ich nicht das es wirklich Sinn macht dieses aus einem Programm heraus aufzurufen. Das ist halt ein Helpertool für die Shell.

Gruß

Claus

 

[beta20]

Also die DB läuft auf dem gleichen Rechner wie der App-Server (Wildfly).
Der Aufruf der export - Methode soll aber natürlich auch von einem Client möglich sein.

 

[Thallius]

Soll denn wirklich die Datenbank mit Struktur exportiert werden oder geht es um die Daten?

 

[BuckRogers]

1. Wenn es darum geht Daten in einer bestimmten Struktur zu erzeugen/extrahieren, dann ist das definitiv Bestandteil der Anwendung im WildFly. Dies sollte dann in der eigentlichen Anwendung geschehen und man sollte möglichst keine Shell commands ausführen sondern die Daten über DAOs laden und aufbereiten bzw. perstieren.

2. Wenn es darum geht einen Dump zu ziehen/importieren, dann ist das eher eine administrative Aufgabe und sollte sich überlegen dafür dann eher ein 'externes' Tool (außerhalb des AS) zu verwenden. Man könnte dann zum Beispiel Quartz- oder Cronjobs laufen lassen, welche periodisch die Shellcommands ausführen.

Btw: Ich verstehe nicht wieso das Importieren von Dumps eine Aufgabe vom AS sein soll? Der AS managed die Anwendung, welche die Daten so erzeugt(Nutzereingaben etc.), wie sie dann im Endeffekt vorliegen.

Was genau ist denn der Grund wieso du einen Dump importieren willst? Wenn wir das verstehen können wir dir bestimmt viel besser weiterhelfen.

 

[beta20]

hallo zusammen,

ich habe eine Anwendung geschrieben, die man auf seinem lokalen Rechner installiert.
Diese Anwendung beinhaltet einen App-Server (Wildfly) und als DB (MySQL).
Die Applikation wird in einem lokalen Netz verwendet, also nicht im Internet.

Was ich benötige ist, dass ich ein Backup erstelle aller Daten, die jemals von dem User erstellt wurden.
Beispiel: Kunden, Einstellungen etc.
Also ganz klassisch:
1)
Software wird deinstalliert-> Backup wird davor erstellt (über meine Webapp-> der User soll NICHT direkt auf die DB kommen!!!)

2)
Software wird wieder installiert -> Backup soll wieder eingespielt werden und alle Daten sind wieder da.

Zur Info:
Prinzipiell kann es auch sein, dass sich die Datenbankstruktur bei der erneuten Installation geändert hat (neue Felder kamen durch ein Update dazu etc.) -> nun soll es aber ebenfalls möglich sein das Backup der bereits erstellten Daten einzuspielen.

 

[Tobse]

Okey, danke für die Info.

Was den Installationspfad von MySQL (und damit den Ort von mysqldump) angeht: wohin der Server installiert wird, musst du bei der Installation herausfinden / festlegen. Das liegt mehr oder weniger in deiner Verantwortung; mehr als den Standard-Installationspfad kann ich dir da leider nicht geben. Du kannst auch mal in die MySQL Doku schauen, dort steht vllt. wie man über Umgebungsvariablen und/oder Registry-Einträge den Installationspfad findet.

Was das wieder einspielen angeht: ich bin kein Experte für sowas. Aber grundsätzlich kann ich dir sagen: mysqldump ist nicht das Werkzeug dafür. Denn Fakt ist: einen SQL Query so zu schreiben dass er zukünftige Änderungen übersteht, ist unmöglich. Es wäre dann z.B. nicht möglich ein NOT NULL DEFAULT NULL Feld hinzuzufügen.

Du wirst deine Daten in ein anderes Format exportieren müssen (ich persönlich kann dir da JSON oder XML empfehlen; bin aber wie gesagt kein Experte). In diesem Export wirst du auch die Versionsnummer der Datenstruktur vermerken müssen.
Beim import musst du dann prüfen, ob diese Versionsnummer mit der mglw. neueren (oder älteren!) Version überhaupt kompatibel ist. Um die Daten dann wieder in die DB zu bekommen empfiehlt sich ein O/RM. Du erstellst dann aus den Backup-Dateien neue Domain-Objekte und der O/RM fügt sie in die Datenbank ein. Auf diese Weise sind mehrere Abstraktionsschichten zwischen DB und Backup-Datei, welche im Endeffekt dafür sorgen, dass alle Infos korrekt übernommen werden.

 

[beta20]

Das Backup in XML zu speichern, hatte ich auch bereits vor und schon versucht.
Allerdings ist das dann gescheitert, weil ich nicht wusste wie ich das machen kann:
Eine Entity in XML zu wandeln war nicht das Thema, das Problem war bei meinem Versuch die ganzen Abhängigkeiten zu den anderen anderen Bean (1...n Beziehungen etc.)
Weiterhin war das Problem das Einlesen in die DB.
Hier muss nach meinem Verständnis von mir eine Logik implementiert werden in welcher Reihenfolge die Entities eingelesen werden (z.B. die Entity "Räder" muss vor dem "Auto" eingelesen werden....)

Gibt es hierfür nicht eine Library / Methode oder ähnliches? Oder bin ich tatsächlich der erste, der so etwas braucht?
Ich verwende JPA / Hibernate.

Gibt es hier eine andere Möglichkeit?
Was ich brauche: Ein Backup aller Daten über das Webfrontend. Am Besten:
a) Button wird geklickt
b) Datei wird erstellt auf dem Server
c) User kann die Datei herunterladen

 

[Thallius]

Warum serialisierst du nicht einfach die Daten?

Dann hast du auch direkt alle abhängigkeiten

 

[BuckRogers]

Hi,

verstehe ich das richtig dass ein Admin den Dump remote erzeugt und einspielt?

 

[beta20]

Warum serialisierst du nicht einfach die Daten?

Dann hast du auch direkt alle abhängigkeiten

Wie meinst du das genau? Kenne mich hierzu leider nicht aus.
Ich habe +/- 30 Entities.

Hi,
verstehe ich das richtig dass ein Admin den Dump remote erzeugt und einspielt?

Remote heißt für dich über eine Webseite? Wenn ja: genau so soll es sein. Der "Admin" soll keine Programmier / DB - Kenntnisse besitzen können.
Export: Button in WebApp klicken -> File generieren
Import: Button klicken für Upload -> File uploaden -> alle Daten einspielen

 

[BuckRogers]

Remote heisst einfach nur entfernter Zugriff, egal über welches Protokoll. Wer installiert denn DB, Server und App?

 

[beta20]

Remote heisst einfach nur entfernter Zugriff, egal über welches Protokoll. Wer installiert denn DB, Server und App?

Erfolgt über ein Installationsskript

 

[Thallius]

Dann googlecdoch einfach mal nach Java serialisation

 

[BuckRogers]

Nun. Dieses Skript koennte doch auch den Dump installieren.

 

[beta20]

Dann googlecdoch einfach mal nach Java serialisation

Hier findet man leider nur wie man eine Entity serialisiert. Ich möchte aber komplett alle Entities.

Nun. Dieses Skript koennte doch auch den Dump installieren.

Nein - ich möchte dem Anwender es selbst überlassen, ob er ein Backup einspielen möchte oder nicht.
-> Ich kopiere das WAR - File in den Deployment-Ordner des Wildfly Servers. Beim ersten Start werden die Tabellen automatisch erstellt. Das Schema / DB-User / Passwort muss natürlich davor per Skript erstellt werden.

 

[BuckRogers]

Also man kann auch ganz simpel einfach Sql-skripte ausführen. Mehr ist so ein Dump auch nicht. Beim Erzeugen legst du den einfach im user home ab und laedst ihn hoch.

 

[BuckRogers]

Schau mal hier: jdbc scriptrunner
https://github.com/BenoitDuffez/ScriptRunner

 

[Thallius]

dann solltest du dir das mal richtig durchlesen. Sorry aber ich habe echt den Kaffee auf von Leuten die sich nur die examples ansehen und niemals die Manuals.

Mit serialisation kannst du mit einem Safe alle deine Daten in eine Datei schreiben. Man muss es nur lernen und nicht aus dem Internet kopieren.

Bin dann raus

 

[Thallius]

Schau mal hier: jdbc scriptrunner
https://github.com/BenoitDuffez/ScriptRunner

Mann was sollen diese ganzen sinnlosen Tipps. Ein Dump nützt ihm doch überhaupt nichts. Damit kann er die Daten auch nicht wieder einspielen wenn sich nach einem Update die DB Struktur geändert hat.

Denkt hier überhaupt einer mit?

 

[beta20]

dann solltest du dir das mal richtig durchlesen. Sorry aber ich habe echt den Kaffee auf von Leuten die sich nur die examples ansehen und niemals die Manuals.

Mit serialisation kannst du mit einem Safe alle deine Daten in eine Datei schreiben. Man muss es nur lernen und nicht aus dem Internet kopieren.

Bin dann raus

nach was soll ich denn dann deiner Meinung suchen?

 

[BuckRogers]

@Thallius Sonst geht es dir noch gut oder was? Reiß dich mal zusammen!

@beta20 Um ehrlich zu sein ist das ganze Prinzip Jboss lokal mit DB laufen zu lassen total übertrieben. Das Ding ist dazu da um auf einem Server zu laufen um dann entfernt zu operieren. Die Daten sichert man dann mit regelmäßigen Dumps und logs. Das dumpen der Daten ist nicht dazu gedacht sie über längere Zeit aufzuheben. Die Serialisierung der Daten in ein Trägerformat ist daher der richtige Weg. Ein Dump wäre der einfachere Weg, lässt aber zu viele Probleme offen.

 

[beta20]

Vielleicht habe ich mich nicht ganz richtig ausgedrückt:
Der Jboss läuft auf einem Rechner als Server. Darauf greifen aber verschiedene Clients im Intranet (per WLAN).
Im Prinzip möchte ich ganz simpel:
a) Export erstellen: Button drücken -> File wird generiert mit den Daten aus der Datenbank
b) Import: Button drücken -> File von a) einlesen -> alle Daten sind wieder da (+ Updates beachten, neue Spalte kam dazu in der DB o.ä.)

 

[BuckRogers]

Ah da kommen wir der Sache schon näher

Du willst ja eigentlich nicht die Strukur mit Daten dumpen, sondern du möchtest dass für einen ausgewählten Nutzer seine Daten extrahiert werden und auch wieder importiert werden können, richtig?

 

[JStein52]

Ah da kommen wir der Sache schon näher

Das war doch schon lange klar.

du möchtest dass für einen ausgewählten Nutzer seine Daten extrahiert werden und auch wieder importiert werden können

Nein, möchte er nicht. Steht doch oben was er möchte.

 

[beta20]

Also:
1)
Ich habe eine Web-App, die auf einem lokalen PC in einem Netzwerk läuft (also quasi mein Server).

2)
Als App-Server wird Wildfly und Datenbank MySQL eingesetzt. Derjenige, der die Software installiert hat (im Folgenden Admin genannt), soll nicht direkt an die Datenbank kommen (Struktur soll ihn nicht interessieren).

3)
Der Admin möchte ich ein Backup aller Daten machen, die jemals in die Datenbank gespeichert wurden

4)
Als Backup soll eine Datei erstellt werden, die alle Daten enthält, die in der DB stehen.
Das Backup wird folgendermaßen erstellt:
- Klick auf einen Button "Backup erstellen"
- File wird generiert und zum Download bereitgestellt im Webbrowser

5)
Aus welchem Grund auch immer, möchte der Admin das Backup wieder einspielen. Gründe wären:
- Update der Software
- Software deinstalliert...

Die Datei wird über den Web Browser eingespielt, in dem die Datei einfach wieder hochgeladen wird.

Die goldene Frage ist nun immer noch, wie ich das Backup erstelle, sodass auch geänderte Datenbankstrukturen (durch Updates) keine Probleme darstellen.
Wie kann ich das machen? Ich habe soetwas noch nicht implementiert, aber ich werde doch nicht der erste sein, der so etwas vorhabt?

 

[Thallius]

Ich könnte jetzt ja sagen serialisierung aber ich lass es, hat ja eh keinen Sinn...

 

[beta20]

Ich könnte jetzt ja sagen serialisierung aber ich lass es, hat ja eh keinen Sinn...

Du kannst es gerne erklären

 

[JStein52]

z.B. hier mal als Einstieg: http://openbook.rheinwerk-verlag.de...17_010.htm#mjfbe8cb1105d7dfaf6adbc23f31c81b93

 

[DerUnwissende]

@Thallius Serialisierung ist keine gute Idee, wenn sich Klassen zwischen 2 Versionen ändern, hast du keine Chance wieder zu deserialisieren.

@beta20 Wäre nicht die einfachste Lösung, dass du den Pfad zu mysql in die PATH-Umgebungsvariable einträgst? Dann kannst du mysqldump ohne Pfad aufrufen. Alternativ ginge SELECT ... INTO OUTFILE[1] und LOAD DATA INFILE[2], das musst du aber dann pro Tabelle machen.

Für Software-Updates mit strukturellen Änderungen bieten sich Tools wie liquibase[3] oder flyway[4] an. In deinem Fall wäre liquibase wahrscheinlich besser, da sich das bei JBoss so integrieren lässt, dass die neuen Änderungen beim Start der Applikation ausgeführt werden können.

[1] http://dev.mysql.com/doc/refman/5.7/en/select-into.html
[2] http://dev.mysql.com/doc/refman/5.7/en/load-data.html
[3] http://www.liquibase.org/
[4] https://flywaydb.org/

 

[JStein52]

Irgendwie dreht sich dieser Thread im Kreis. Es gibt zwar ständig einen Tip für ein neues Tool aber letztlich muss er die Daten die zu einem bestimmten DB-Stand passen migrieren damit er sie in eine neue DB importieren kann. Und das betrifft im Grunde genommen auch die Serialisierung/Deserialisierung. Und der TE denkt wohl er findet da etwas das das für ihn erledigt. Das glaube ich aber nicht und er wird da wohl was selber machen müssen.

 

[beta20]

Zunächst danke für die Hilfen, leider sind bei mir noch einige Fragen offen, sodass ich nicht weiß, was nun...

Also ich benötige nicht zwingend einen kompletten Export des Schemas, denn beim Hochfahren des Wildfly - Servers wird ohnehin geprüft, ob sich beim Schema in der vorhandenenen DB sich etwas geändert hat.
Das Schema wird bei der Installation der App ohne hin angelegt.
-> Beim ersten Start des Wildfly- Servers werden die Tabellen automatisch per Hibernate erstellt, sofern sie noch nicht vorhanden sind.

Demnach benötige ich eig. nur die insert-Statements (ich lasse mich aber auch gerne eines besseren belehren).
Sofern das Export Skript etwas beinhaltet wie "create table if not exists" wäre das auch ok.
Welches Tool kann ich dafür am Besten verwenden?

 

[BuckRogers]

@JStein52 Komische Kommentare tragen nicht zur Lösung bei. Besonders nicht, wenn man damit auch noch falsch liegt. Dies ist ein recht komplexes Thema. Zu dem Problem gibt es mehrere Lösungen. Um ein passende Lösung zu finden, muss man das Problem in seiner Fülle verstehen. Deswegen Frage ich lieber fünf mal nach, damit man eventuell eine andere Herangehensweise in Betracht ziehen kann. Ich finde nicht, dass man daran etwas aussetzen muss.

@Thallius Dieses zickenhafte Auftreten trägt ebenfalls zu keinem Ansatz bei. Einfach nur Serialisierung zu schreien, im Thread rumpöbeln und dann verschwinden finde ich jetzt nicht so toll. Immerhin beteiligt man sich hier in seiner Freizeit. Nobody is perfect.

@beta20 Ich habe gute Erfahrung mit flyway gemacht um die die DB zu aktualisieren. Du wirst halt nur Probleme haben Dumps zu importieren wenn sich das Tabellenschema ändert. Eine effektive Lösung wäre zum Beispiel mit flyway:

1. Datenbank exportieren (Flyway Version 1)
... zwischenzeitlich ändert sich die Datenstruktur für die Anwendung auf Flyway Version 2
2. Server aufsetzen + Dump einspielen (Flyway Version 1)
3. Datenbank updaten auf Flyway Version 2

Somit kann man mit den alten Daten auf der neuen Struktur arbeiten.
Was nicht funktioniert ist, die Daten bei der neueren DB-Struktur einpielen.

 

[JStein52]

1. Datenbank exportieren (Flyway Version 1)
... zwischenzeitlich ändert sich die Datenstruktur für die Anwendung auf Flyway Version 2
2. Server aufsetzen + Dump einspielen (Flyway Version 1)
3. Datenbank updaten auf Flyway Version 2

Das was du hier beschreibst ist eine Null-Aussage ! Was soll man denn jetzt damit anfangen ?

 

[BuckRogers]

Das was du hier beschreibst ist eine Null-Aussage ! Was soll man denn jetzt damit anfangen ?

Das ist die Verfahrensweise wie man ältere Daten in ein DB-Schema integriert, welches neuer ist als das im Dump. Und das ist übrigens auch die Aussage. Und deine komische Einstellung kannst du mal bei Seite lassen. Das ist unprofessionell, fast peinlich.

 

[JStein52]

Na dann ist ja jetzt alles geklärt und der TE braucht es nur so zu machen. Aber Spass beiseite: ich halte das trotzdem nicht für eine neue Aussage. Denn was du sagst ist: Importiere die Daten in die alte Datenbank und migriere dann die Datenbank auf die neue Version. Das ist trivial und deshalb eine Null-Aussage.

 

[DerUnwissende]

Demnach benötige ich eig. nur die insert-Statements (ich lasse mich aber auch gerne eines besseren belehren).

Es kommt drauf an was für Änderungen du hast. Nehmen wir mal an du schreibst ein Personenverwaltungsprogramm. Am Anfang hast du folgende Klasse:

public class Person {
   long id;
   String name;
}

Hibernate macht dann diese Tabelle draus

ID NAME
---- --------
1 beta20

Wenn du das dann exportierst bekommst du:

INSERT INTO Person(ID,NAME) VALUES(1,'beta20');

Fügst du jetzt ein neues Attribut dazu, wie zum Beispiel ein Land, wird auch in deiner Tabelle eine Spalte hinzugefügt:

ID NAME LAND
---- --------------- ------
1 beta20
2 derUnwissende DE

Dein Insert von oben würde auch in der neuen Struktur funktionieren. Wenn du jetzt exportierst bekommst du dann:

INSERT INTO Person(ID,NAME,LAND) VALUES(1,'beta20',null);
INSERT INTO Person(ID,NAME,LAND) VALUES(2,'derUnwissende','DE');

Wenn wir aber jetzt das Land wieder weg nehmen und wieder die Tabelle vom 1. Schritt haben, dann können wir nicht mehr den Export aus dem 2. Schritt verwenden, da mySQL dir beim Import sagen wird, dass es die Spalte "LAND" nicht gibt.

Dein Ansatz funktioniert, solange du nur Spalten hinzufügst, aber sobald du Spalten löschst, umbenennst oder verschiebst, funktioniert dein Ansatz nicht.

Ein Dump alleine, hilft dir nur solange du die selbe Version nutzt, oder nur Spalten hinzufügst. Wie du diesen aus deinem Programm raus generieren kannst, hab ich dir ja schon oben geschrieben.

Falls du aber größere Strukturänderungen machst, musst du dir überlegen, wie du von einer Version zur nächsten kommst. Dazu brauchst du dann sowas wie liquibase oder flyway.