Open JohannMaierhofer opened 4 months ago
Wie hast Du das eigentlich mit MySQL getestet? Ich arbeite mit meiner Live-Umgebung mit einer MySQL-Datenbank und würde gerne mit Klonen dieser Datenbank hier arbeiten. Dann brauch ich nicht immer Test-Mitglieder anzulegen. Gibt es denn eine Möglichkeit, beim Debuggen statt mit der H2-Datenbank mit einer MySQL-Datenbank zu arbeiten? Ich hab das mit dieser Anleitung versucht. In der Live-Umgebung hat das funktioniert, bei meinen Tests hier funktioniert das nicht: https://doku.jverein.de/allgemein/mysql-support
Beim Löschen eines Mitglieds, dem Buchungen zugeordnet sind und für den auch eine Spendenquittung erstellt wurde, wird folgende Meldung protokolliert:
Fehler beim Löschen des Mitgliedes java.rmi.RemoteException: delete failed, rollback successful; nested exception is: org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Referentielle Integrität verletzt: "FKSPENDENBESCHEINIGUNG2: PUBLIC.SPENDENBESCHEINIGUNG FOREIGN KEY(MITGLIED) REFERENCES PUBLIC.MITGLIED(ID) (2)" Referential integrity constraint violation: "FKSPENDENBESCHEINIGUNG2: PUBLIC.SPENDENBESCHEINIGUNG FOREIGN KEY(MITGLIED) REFERENCES PUBLIC.MITGLIED(ID) (2)"; SQL statement: delete from MITGLIED where ID = 2 [23503-199] at de.willuhn.datasource.db.AbstractDBObject.delete(AbstractDBObject.java:390) at de.jost_net.JVerein.gui.action.MitgliedDeleteAction.handleAction(MitgliedDeleteAction.java:117) at de.willuhn.jameica.gui.parts.ContextMenu$1.handleEvent(ContextMenu.java:184) at org.eclipse.swt.widgets.EventTable.sendEvent(EventTable.java:89) at org.eclipse.swt.widgets.Display.sendEvent(Display.java:5855) at org.eclipse.swt.widgets.Widget.sendEvent(Widget.java:1529) at org.eclipse.swt.widgets.Display.runDeferredEvents(Display.java:5065) at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java:4517) at de.willuhn.jameica.gui.GUI.loop(GUI.java:938) at de.willuhn.jameica.gui.GUI.init(GUI.java:335) at de.willuhn.jameica.system.Application.init(Application.java:145) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78) Caused by: org.h2.jdbc.JdbcSQLIntegrityConstraintViolationException: Referentielle Integrität verletzt: "FKSPENDENBESCHEINIGUNG2: PUBLIC.SPENDENBESCHEINIGUNG FOREIGN KEY(MITGLIED) REFERENCES PUBLIC.MITGLIED(ID) (2)" Referential integrity constraint violation: "FKSPENDENBESCHEINIGUNG2: PUBLIC.SPENDENBESCHEINIGUNG FOREIGN KEY(MITGLIED) REFERENCES PUBLIC.MITGLIED(ID) (2)"; SQL statement: delete from MITGLIED where ID = 2 [23503-199] at org.h2.message.DbException.getJdbcSQLException(DbException.java:457) at org.h2.message.DbException.getJdbcSQLException(DbException.java:427) at org.h2.message.DbException.get(DbException.java:205) at org.h2.message.DbException.get(DbException.java:181) at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:373) at org.h2.constraint.ConstraintReferential.checkRowRefTable(ConstraintReferential.java:390) at org.h2.constraint.ConstraintReferential.checkRow(ConstraintReferential.java:265) at org.h2.table.Table.fireConstraints(Table.java:1020) at org.h2.table.Table.fireAfterRow(Table.java:1038) at org.h2.command.dml.Delete.update(Delete.java:129) at org.h2.command.CommandContainer.update(CommandContainer.java:133) at org.h2.command.Command.executeUpdate(Command.java:267) at org.h2.jdbc.JdbcStatement.executeUpdateInternal(JdbcStatement.java:169) at org.h2.jdbc.JdbcStatement.executeUpdate(JdbcStatement.java:126) at de.willuhn.datasource.db.AbstractDBObject.delete(AbstractDBObject.java:372) ... 12 more
Ich habe auch mit MySQL getestet. In der Beschreibung im Online Help ist leider etwas abgeschnitten. Ich habe folgendes in der Datei de.jost_net.JVerein.rmi.JVereinDBService.properties:
database.driver=de.jost_net.JVerein.server.DBSupportMySqlImpl database.driver.mysql.jdbcurl=jdbc\:mysql\://localhost\:3306/jverein?useUnicode\=Yes
database.driver.mysql.username='jverein' database.driver.mysql.password=jverein database.driver.mysql.scriptprefix=mysql-database.driver.mysql.jdbcdriver=org.mariadb.jdbc.Driver
Das hatte ich irgendwo anders gefunden. Die letzte Zeile ist in der Help abgeschnitten. Jedenfalls hatte es ohne die Änderung nicht funktioniert. Ich habe die Maria DB. Bei MySQL muss man wahrscheinlich com.mysql.jdbc.Driver hinten angeben oder man kann es da dann weg lassen und so lassen wie in der Online Help.
Bezüglich deinem Problem. Du hast wohl nicht die SW aus meinem Branch. Denn sonst sollte beim Delete mein neuer Dialog kommen.
Ja stimmt. Als ich es das erste Mal ausprobiert habe, lief irgendwie noch der alte Code. Jetzt habe ich aber Deinen Code.
Der Fehler tritt bei mir in Zeile 117 auf:
Es scheint, dass der Fehler in der Datei AbstractDBObject.java auftritt (wohl in Zeile 390: de.willuhn.datasource.db.AbstractDBObject.delete(AbstractDBObject.java:390), für die ich aber grad keine Quelltexte habe. Wahrscheinlich mach ich wieder nur irgendwas falsch ;-)
Das ist seltsam. Kannst du mal schauen ob die Datenbank Migration 440 auch durchgeführt wurde. Also, ob der aktuelle Stand der Datenbank auf 440 steht. Das müsste im JVerein About Dialog stehen.
Nein, da steht jetzt 437. Wieso auch immer:
Die Datei ist aber da:
438 und 439 fehlen. Vielleicht ist ja das ein Problem? Muss die Nummerierung fortlaufend sein? Die sind aber in Github auch nicht da. (Bitte entschuldige, dass ich mich so anstelle, aber ich hab das noch nicht so oft gemacht...)
Hier noch ein Auszug aus dem Log. Auch hier geht die Zählung nur bis 437. Ich weiß aber nicht, ob das Stoppen des DB-Dienstes so stimmt oder nicht:
[Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run] JVerein-DB-Update: 436 ... [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.setNewVersion] JVerein-DB-Update: 436 [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] starting transaction [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] commit transaction [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run] JVerein-DB-Update: 437 ... [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.setNewVersion] JVerein-DB-Update: 437 [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.stop] stopping db service [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] commit connection [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] closing connection [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] connection closed [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.stop] db service stopped [1 connection(s) closed] [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.jameica.services.ArchiveService.init] checking jameica.messaging availability [Fri Jul 19 08:55:27 CEST 2024][INFO][main][de.willuhn.jameica.messaging.LookupService.lookup] performing multicast lookup for service name: tcp:de.willuhn.jameica.messaging.Plugin.connector.tcp [Fri Jul 19 08:55:32 CEST 2024][INFO][main][de.willuhn.jameica.messaging.LookupService.lookup] no server found for service name: tcp:de.willuhn.jameica.messaging.Plugin.connector.tcp [Fri Jul 19 08:55:32 CEST 2024][WARN][main][de.willuhn.jameica.services.ArchiveService.init] no archive server found [Fri Jul 19 08:55:32 CEST 2024][ERROR][main][de.willuhn.jameica.plugin.Version.parse] unparsable version part: [VERSION]
Wenn ich die Migration in 438 umbenenne, klappt alles.
Wenn ich die Migration in 438 umbenenne, klappt alles.
Dann hast du aber nicht wirklich den aktuellen Stand der SW. Es existieren ja auch die Migrationen 438 und 439. 440 war darum schon richtig. Da die Nummerierung fortlaufend ist wurde bei dir dann die 440 nicht ausgeführt. Jetzt hast du ein Problem mit der eigentlichen Migration 438. Wenn es eine Test Datenbank war kannst du sie löschen. Ansonsten müsstest du mit einem Datenbank Editor die Version auf 437 zurücksetzen und dann die richtigen Migrationen machen. Die 440 doppelt ausführen sollte gehen.
Ganz verstehen tu ich das aber noch nicht. Ich habe einfach Deinen Branch ausgecheckt. Da sollte doch alles drin sein, oder?
War eine Test-Datenbank, ja. Ist nix kaputt gegangen. 👍
Das wahr wohl mein Problem. In meinem Branch haben die 438 und 439 gefehlt. Da bei mir die schon ausgeführt waren weil ich die entsprechenden Features die diese eingeführt haben schon benutzt hatte, ist das bei mir nicht aufgefallen. Ich habe jetzt den aktuellen Stand aus dem Main in das Feature gemerged. Jetzt sind die anderen Migrationen auch dabei.
Der Feature-Wunsch in #213 kommt von @mbmueller - daher sollte er das Review durchführen.
Bei mir bricht das Update0440 mit nachfolgender Meldung ab, obwohl der key existiert.
[Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.jost_net.JVerein.server.JVereinDBServiceImpl.
[Sun Jul 21 10:02:58 CEST 2024][DEBUG][main][de.willuhn.sql.ScriptExecutor.execute] reading sql script
[Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] starting transaction
[Sun Jul 21 10:02:58 CEST 2024][DEBUG][main][de.willuhn.sql.ScriptExecutor.execute] executing: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
[Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] rollback transaction
[Sun Jul 21 10:02:58 CEST 2024][ERROR][main][de.willuhn.sql.ScriptExecutor.execute] error while executing sql script. Current statement: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
java.sql.SQLSyntaxErrorException: (conn=8) Can't DROP 'fk_sekundaerbeitragegruppe1'; check that column/key exists
at org.mariadb.jdbc.export.ExceptionFactory.createException(ExceptionFactory.java:282)
at org.mariadb.jdbc.export.ExceptionFactory.create(ExceptionFactory.java:370)
at org.mariadb.jdbc.message.ClientMessage.readPacket(ClientMessage.java:134)
at org.mariadb.jdbc.client.impl.StandardClient.readPacket(StandardClient.java:872)
at org.mariadb.jdbc.client.impl.StandardClient.readResults(StandardClient.java:811)
at org.mariadb.jdbc.client.impl.StandardClient.readResponse(StandardClient.java:730)
at org.mariadb.jdbc.client.impl.StandardClient.execute(StandardClient.java:654)
at org.mariadb.jdbc.Statement.executeInternal(Statement.java:957)
at org.mariadb.jdbc.Statement.executeUpdate(Statement.java:939)
at org.mariadb.jdbc.Statement.executeUpdate(Statement.java:175)
at de.willuhn.sql.ScriptExecutor.execute(ScriptExecutor.java:166)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:89)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:76)
at de.jost_net.JVerein.server.DDLTool.Updates.Update0440.run(Update0440.java:32)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at de.jost_net.JVerein.server.JVereinUpdateProvider.callMethod2(JVereinUpdateProvider.java:266)
at de.jost_net.JVerein.server.JVereinUpdateProvider.
[Sun Jul 21 10:02:58 CEST 2024][ERROR][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute] unable to execute update
java.sql.SQLException: exception while executing sql script: (conn=8) Can't DROP 'fk_sekundaerbeitragegruppe1'; check that column/key exists. Current statement: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
at de.willuhn.sql.ScriptExecutor.execute(ScriptExecutor.java:195)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:89)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:76)
at de.jost_net.JVerein.server.DDLTool.Updates.Update0440.run(Update0440.java:32)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at de.jost_net.JVerein.server.JVereinUpdateProvider.callMethod2(JVereinUpdateProvider.java:266)
at de.jost_net.JVerein.server.JVereinUpdateProvider.
[Sun Jul 21 10:02:58 CEST 2024][ERROR][main][de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency] Datenbankupdate kann nicht ausgeführt werden.
de.willuhn.util.ApplicationException
at de.jost_net.JVerein.server.JVereinUpdateProvider.
Server-Version: 8.4.1 - MySQL Community Server
Du hast den MySQL Community Server. Im Trace steht org.mariadb.jdbc.client... Kann es sein, dass der Treiber nicht passt?
Den SQL client musste ich auf mariadb umstellen, da ich mit Jameica und Hibiscus master (v 2.11) arbeitete. Dort gibt es kein MySQL mehr. Ich bin auf die branches 2_10 gewechselt und habe wieder auf MySQL gestellt. Auch hier passiert das selbe:
[Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.jost_net.JVerein.server.JVereinDBServiceImpl.
[Sun Jul 21 11:19:10 CEST 2024][DEBUG][main][de.willuhn.sql.ScriptExecutor.execute] reading sql script
[Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] starting transaction
[Sun Jul 21 11:19:10 CEST 2024][DEBUG][main][de.willuhn.sql.ScriptExecutor.execute] executing: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
[Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.sql.ScriptExecutor.execute] rollback transaction
[Sun Jul 21 11:19:10 CEST 2024][ERROR][main][de.willuhn.sql.ScriptExecutor.execute] error while executing sql script. Current statement: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Can't DROP 'fk_sekundaerbeitragegruppe1'; check that column/key exists
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
at java.base/jdk.internal.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:45)
at java.base/java.lang.reflect.Constructor.newInstanceWithCaller(Constructor.java:499)
at java.base/java.lang.reflect.Constructor.newInstance(Constructor.java:480)
at com.mysql.jdbc.Util.handleNewInstance(Util.java:403)
at com.mysql.jdbc.Util.getInstance(Util.java:386)
at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:944)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3933)
at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3869)
at com.mysql.jdbc.MysqlIO.sendCommand(MysqlIO.java:2524)
at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2675)
at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2465)
at com.mysql.jdbc.StatementImpl.executeUpdateInternal(StatementImpl.java:1536)
at com.mysql.jdbc.StatementImpl.executeLargeUpdate(StatementImpl.java:2585)
at com.mysql.jdbc.StatementImpl.executeUpdate(StatementImpl.java:1464)
at de.willuhn.sql.ScriptExecutor.execute(ScriptExecutor.java:166)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:89)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:76)
at de.jost_net.JVerein.server.DDLTool.Updates.Update0440.run(Update0440.java:32)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at de.jost_net.JVerein.server.JVereinUpdateProvider.callMethod2(JVereinUpdateProvider.java:266)
at de.jost_net.JVerein.server.JVereinUpdateProvider.
[Sun Jul 21 11:19:10 CEST 2024][ERROR][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute] unable to execute update
java.sql.SQLException: exception while executing sql script: Can't DROP 'fk_sekundaerbeitragegruppe1'; check that column/key exists. Current statement: ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1
at de.willuhn.sql.ScriptExecutor.execute(ScriptExecutor.java:195)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:89)
at de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute(AbstractDDLUpdate.java:76)
at de.jost_net.JVerein.server.DDLTool.Updates.Update0440.run(Update0440.java:32)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:77)
at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.base/java.lang.reflect.Method.invoke(Method.java:568)
at de.jost_net.JVerein.server.JVereinUpdateProvider.callMethod2(JVereinUpdateProvider.java:266)
at de.jost_net.JVerein.server.JVereinUpdateProvider.
[Sun Jul 21 11:19:10 CEST 2024][ERROR][main][de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency] Datenbankupdate kann nicht ausgeführt werden.
de.willuhn.util.ApplicationException
at de.jost_net.JVerein.server.JVereinUpdateProvider.
[Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.stop] stopping db service [Sun Jul 21 11:19:10 CEST 2024][DEBUG][main][de.willuhn.datasource.db.DBServiceImpl.stop] db service: object cache matches: 50 % [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] commit connection [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] closing connection [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.closeConnection] connection closed [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.stop] db service stopped [1 connection(s) closed] [Sun Jul 21 11:19:10 CEST 2024][ERROR][main][de.willuhn.jameica.plugin.PluginLoader.init] unable to init plugin jverein: de.willuhn.util.ApplicationException [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.jameica.gui.SplashScreen$3.run] init plugin jameica.messaging [Version: 2.11.0-nightly] ...
Ich gehe davon aus, dass nicht der index name "fk_sekundaerbeitragegruppe1" gelöscht werden muss, sondern der (automatisch generierte) constraint name "sekundaerebeitragsgruppe_ibfk_1", oder beides.
Ja, man muss den Constraint löschen. Dann ist es aber bei MYSQL ganz anders als bei H2. Hier hat der Constraint den Namen "fk_sekundaerbeitragegruppe1".
Jetzt schaue ich nochmal warum die Migration bei meinen Tests bei MariaDB funktioniert hat.
Bei mir heißt auch der Constraint "fk_sekundaerbeitragegruppe1", allerdings ist das Bild von nach der Migration.
Ich hatte eine neue Datenbank mit MariaDB erzeugt und es sind dann alle Migrationen durchgelaufen.
Ich habe schon in einem Kommentar zu #223 geschrieben, dass ich glaube, dass der Befehl zum Generieren des Key im Code zu MySQL nicht ganz stimmt. Das denke ich führt jetzt zu diesem Fehler. Ich kann jetzt im Code zwischen H2 und MySQL unterscheiden, aber wie unterscheide ich zwischen MariaDb und MySql? Scheinbar ist es da auch unterschiedlich.
Hier noch einmal mein Kommentar zu #223.
Ich habe mir hier das Create Statement aus der MySQL Dokumentation geholt.
ADD [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (col_name,...)
So wie ich es verstanden habe ist symbol der Contraint Name und index_name der Name des Indexes der auf die Spalte erzeugt wurde.
Der aktuelle Code setzt bei MySQL den übergeben Contraint Namen als index_name ein. Das wäre aber falsch weil der Index einen anderen Namen hat. Für das Löschen des Foreign Key muss man den symbol Namen nehmen.
ALTER TABLE tbl_name DROP FOREIGN KEY fk_symbol <--- das habe ich geändert
Da der bei MySQL nicht angegeben ist wird er wohl automatisch generiert. Dann funktioniert mein Upgrade440 nicht weil zum Löschen der übergebene Contraint Name benutzt wird.
Darum glaube ich, dass die Methode createForeignKey nicht stimmt.
Jetzt habe ich noch etwas gefunden. Die spec sagt: For ALTER TABLE, unlike CREATE TABLE, ADD FOREIGN KEY ignores index_name if given and uses an automatically generated foreign key name. As a workaround, include the CONSTRAINT clause to specify the foreign key name:
Also wird wohl beim aktuellen Code der Contraint Name sowieso ignoriert und einer automatisch generiert. Es wäre aber wohl besser den Request zu ändern und den Namen als Symbol zu übergeben wie bei H2.
Der Feature-Wunsch in #213 kommt von @mbmueller - daher sollte er das Review durchführen.
Würde ich gerne. Habe im Moment aber keine Zeit, erst wieder Mitte August. Außerdem hat sich bei mir die IDE wieder zerschossen. Kann man das Projekt irgendwie mal abändern, dass das ohne großen Aufwand in IntelliJ läuft?
@dippeal könntest du mir die Namen der Foreign Keys aus deiner Datenbank auflisten. Ich hoffe dann mal dass sie auch bei anderen dann so automatisch genereiert worden sind. Den Code würde ich dann so ändern, dass ich zwischen H2 und MySql unterscheide. Bei MySql kann ich es erst mit den H2 Namen probieren wegen MariaDB und wenn es eine Exception gibt dann nehme ich die anderen Namen.
Frage: Wo wird denn eigentlich beim ersten Start die neue leere Datenbasis erzeugt?
@dippeal könntest du mir die Namen der Foreign Keys aus deiner Datenbank auflisten. Ich hoffe dann mal dass sie auch bei anderen dann so automatisch genereiert worden sind. Den Code würde ich dann so ändern, dass ich zwischen H2 und MySql unterscheide. Bei MySql kann ich es erst mit den H2 Namen probieren wegen MariaDB und wenn es eine Exception gibt dann nehme ich die anderen Namen.
Von allen Tabellen oder bestimmten?
Ich dachte nur an die, die in der Migrationen vorkommen. Du musst das nicht mehr machen. Ich habe vor auf einem zweiten PC eine MySQL Datenbank zu installieren, dann kann ich auch selbst testen ob es funktioniert. Und auch zukünftige Migrationen kann ich dann selbst testen.
Ich habe jetzt die Änderung für MySql gemacht. Die unterschiedlichen Namen gab es nur bei dem einen Attribut. Das liegt wohl daran, dass sie automatisch generiert wurden. H2 und MariaDB benutzen da anscheinend den gleichen Algorithmus. Nur bei MySQL war der generierte Name anders. Beim testen habe ich wie vermutet festgestellt, dass MySQL wieder neue Namen generiert und nicht die übergebenen benutzt. Damit wurden dann auch alle anderen Namen die bisher gleich waren bei MySql geändert. Ich habe dann meinen Vorschlag implementiert und die createForeignKey Methode für MYSQL so geändert wie es bei H2 ist, also den Constraint Namen zwischen CONSTRAINT und FOREIGN KEY. Dann wurden auch die übergebenen Namen gesetzt und keine Namen automatisch generiert. Ich habe das Ganze mit H2, MySQL und MariaDB getestet. Sowohl ein Upgrade von der Version 21 als auch mit einer neuen Datenbasis.
Update lief zwar durch, scheint aber nicht so sauber.
Update lief zwar durch, scheint aber nicht so sauber.
Warum, wegen des gleichen Namens wie der Index?
Ansonsten wollte ich jetzt die gleichen Namen wie bei H2 benutzen.
Wunderte mich, dass die sekundaerebeitragsgruppe_ibfk_2 nicht auch im neuen Namensschema ist.
Wunderte mich, dass die sekundaerebeitragsgruppe_ibfk_2 nicht auch im neuen Namensschema ist.
Diesen Foreign Key habe ich ja nicht geändert.
Ich werde jetzt trotzdem mal den Namen anders wählen als den Index. Ich weiß nicht ob das sonst Probleme bereiten könnte. Ich nehme wieder den alten Namen von H2.
Ich habe jetzt das "_" reingemacht. Jetzt sind die Namen für Key und Constraint trotzdem gleich. Es übernimmt wohl den Constraint Namen als Schlüsselname. Durch meine Änderung des createForeignKey wird jetzt der Constraint Name explizit gesetzt und der Schlüssel automatisch gesetzt. Früher war es umgekehrt.
Musste noch Kleinschrift bei fk_sekundaerbeitragegruppe1 machen analog zu Upgrade0394.
Bei dieser Migration (Upgrade0394) wird übrigens der automatisch generierte Name bei MySql erzeugt. Wenn die Migration mit dem aktuellen Code läuft entsteht hier kein automatisch generierter Name mehr.
Wegen der Migration muss erst #225 übernommen werden.
Du hast Recht, ich schaue mal wie das geht.
Jetzt werden auch die Dokumente gelöscht. Ich habe das gleich analog auch bei den Buchungen gemacht. Damit funktioniert das DBBereinigen richtig.
Ich löse den Mergekonflikt wenn noch jemand reviewt. Vorher lasse ich mal #296 Vorrang.
Habe den Code auf aktuellen Stand gebracht (Merge Master) und Merge Konflikt wegen Upgrade0442 behoben. Der Upgrade0443 ist gleich wie #296. Je nachden wer erster übernommen wird muss ich den anderen dann anpassen.
Mit diesem Feature lassen sich Mitglieder DSGVO konform löschen (siehe Issue #213). Es werden alle Datensätze die auf das Mitglied verweisen ebenfalls gelöscht. Mails werden nur gelöscht wenn das Mitglied der einzige Empfänger war. Buchungen in den Konten bleiben erhalten, einerseits wegen der Aufbewahrungsfristen und andererseits weil sonst die Buchführung auch nicht mehr stimmen würde. Der Löschen Dialog gibt eine entsprechende Warnung aus:![Screenshot_20240505_094937](https://github.com/openjverein/jverein/assets/126261667/97ad628c-aefc-4fc2-ac94-d9a5805ba48c)
Zu den Änderungen:
PS: Foreign Keys kann man nicht modifizieren sondern muss sie erst löschen und wieder neu erzeugen. Ich habe in AbstractDDLUpdate die Methode zum Löschen des Foreign Key implementiert. Das funktioniert bei h2db und MySql unterschiedlich. Habe es jetzt auch mit MySQL getestet. Es geht nach dem ich auf Kleinschreibung korrigiert habe.