search

openjverein / jverein

Open JVerein - Open Source Vereinsverwaltung
https://openjverein.github.io
GNU General Public License v3.0
42 stars 15 forks source link

DSGVO konformes Löschen von Mitgliedern, implementiert #213 #224

Open JohannMaierhofer opened 4 months ago

JohannMaierhofer commented 4 months ago

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

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.

SchachtnerTh commented 1 month 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

SchachtnerTh commented 1 month ago

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

JohannMaierhofer commented 1 month ago

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

&characterEncoding\=ISO8859_1

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.

SchachtnerTh commented 1 month ago

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: image

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 ;-)

JohannMaierhofer commented 1 month ago

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.

SchachtnerTh commented 1 month ago

Nein, da steht jetzt 437. Wieso auch immer: image

Die Datei ist aber da: image

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]

SchachtnerTh commented 1 month ago

Wenn ich die Migration in 438 umbenenne, klappt alles.

JohannMaierhofer commented 1 month ago

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.

SchachtnerTh commented 1 month ago

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. 👍

JohannMaierhofer commented 1 month ago

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.

willuhn commented 1 month ago

Der Feature-Wunsch in #213 kommt von @mbmueller - daher sollte er das Review durchführen.

dippeal commented 1 month ago

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.] loading database driver: de.jost_net.JVerein.server.DBSupportMySqlImpl [Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.start] starting db service [Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.createConnection] creating new connection [Sun Jul 21 10:02:58 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.getConnection] created new connection for [Sun Jul 21 10:02:58 CEST 2024][DEBUG][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute] ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1;

[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.(JVereinUpdateProvider.java:93) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78)

[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.(JVereinUpdateProvider.java:93) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78) Caused by: 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) ... 23 more

[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.(JVereinUpdateProvider.java:100) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78)

Server-Version: 8.4.1 - MySQL Community Server

image
JohannMaierhofer commented 1 month ago

Du hast den MySQL Community Server. Im Trace steht org.mariadb.jdbc.client... Kann es sein, dass der Treiber nicht passt?

dippeal commented 1 month ago

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.] loading database driver: de.jost_net.JVerein.server.DBSupportMySqlImpl [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.start] starting db service [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.createConnection] creating new connection [Sun Jul 21 11:19:10 CEST 2024][INFO][main][de.willuhn.datasource.db.DBServiceImpl.getConnection] created new connection for [Sun Jul 21 11:19:10 CEST 2024][DEBUG][main][de.jost_net.JVerein.server.DDLTool.AbstractDDLUpdate.execute] ALTER TABLE sekundaerebeitragsgruppe DROP FOREIGN KEY fk_sekundaerbeitragegruppe1;

[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.(JVereinUpdateProvider.java:93) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78)

[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.(JVereinUpdateProvider.java:93) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78) Caused by: 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) ... 23 more

[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.(JVereinUpdateProvider.java:100) at de.jost_net.JVerein.server.DBSupportMySqlImpl.checkConsistency(DBSupportMySqlImpl.java:89) at de.jost_net.JVerein.server.JVereinDBServiceImpl.checkConsistency(JVereinDBServiceImpl.java:114) at de.jost_net.JVerein.JVereinPlugin$1.call(JVereinPlugin.java:112) at de.jost_net.JVerein.JVereinPlugin.call(JVereinPlugin.java:209) at de.jost_net.JVerein.JVereinPlugin.init(JVereinPlugin.java:105) at de.willuhn.jameica.plugin.PluginLoader.initPlugin(PluginLoader.java:394) at de.willuhn.jameica.plugin.PluginLoader.init(PluginLoader.java:239) at de.willuhn.jameica.services.PluginService.init(PluginService.java:39) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:139) at de.willuhn.boot.BootLoader.resolve(BootLoader.java:119) at de.willuhn.boot.BootLoader.getBootable(BootLoader.java:70) at de.willuhn.jameica.system.Application.init(Application.java:103) at de.willuhn.jameica.system.Application.newInstance(Application.java:87) at de.willuhn.jameica.Main.main(Main.java:78)

[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.

image

JohannMaierhofer commented 1 month ago

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".

Bildschirmfoto_20240721_113659

Jetzt schaue ich nochmal warum die Migration bei meinen Tests bei MariaDB funktioniert hat.

JohannMaierhofer commented 1 month ago

Bei mir heißt auch der Constraint "fk_sekundaerbeitragegruppe1", allerdings ist das Bild von nach der Migration.

Bildschirmfoto_20240721_115141

Ich hatte eine neue Datenbank mit MariaDB erzeugt und es sind dann alle Migrationen durchgelaufen.

JohannMaierhofer commented 1 month ago

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.

JohannMaierhofer commented 1 month ago

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.

mbmueller commented 1 month ago

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?

JohannMaierhofer commented 1 month ago

@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.

JohannMaierhofer commented 1 month ago

Frage: Wo wird denn eigentlich beim ersten Start die neue leere Datenbasis erzeugt?

dippeal commented 1 month ago

@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?

JohannMaierhofer commented 1 month ago

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.

JohannMaierhofer commented 1 month ago

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.

dippeal commented 1 month ago

Update lief zwar durch, scheint aber nicht so sauber.

image image

JohannMaierhofer commented 1 month ago

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.

dippeal commented 1 month ago

Wunderte mich, dass die sekundaerebeitragsgruppe_ibfk_2 nicht auch im neuen Namensschema ist.

JohannMaierhofer commented 1 month ago

Wunderte mich, dass die sekundaerebeitragsgruppe_ibfk_2 nicht auch im neuen Namensschema ist.

Diesen Foreign Key habe ich ja nicht geändert.

JohannMaierhofer commented 1 month ago

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.

JohannMaierhofer commented 1 month ago

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.

JohannMaierhofer commented 1 month ago

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.

JohannMaierhofer commented 1 month ago

Wegen der Migration muss erst #225 übernommen werden.

JohannMaierhofer commented 1 month ago

Du hast Recht, ich schaue mal wie das geht.

JohannMaierhofer commented 1 month ago

Jetzt werden auch die Dokumente gelöscht. Ich habe das gleich analog auch bei den Buchungen gemacht. Damit funktioniert das DBBereinigen richtig.

JohannMaierhofer commented 3 weeks ago

Ich löse den Mergekonflikt wenn noch jemand reviewt. Vorher lasse ich mal #296 Vorrang.

JohannMaierhofer commented 2 weeks ago

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.