Fehlermeldung nach Server-Upgrade von v2.0.0.4 auf v2.0.1.0

Hallo Jens,

das System lief jetzt einige Monate mit der Version 2.0.0.4 stabil, bis vor kurzem plötzlich keine Anmeldung mehr möglich war. Beim Start des Systems ist uns jetzt aufgefallen, dass damals anscheinend doch eine (teilweise) Migration auf Datenbankschema 2.0.1.0 durchgeführt wurde.

Die aktuelle Fehlermeldung beim Start der Version 2.0.0.4 lautet:

19:15:31,163 INFO [stdout] (ServerService Thread Pool — 77) Starting j-lawyer.org database migrations…
19:15:31,188 INFO [org.flywaydb.core.internal.license.VersionPrinter] (ServerService Thread Pool — 77) Flyway Community Edition 5.2.1 by Boxfuse
19:15:31,199 INFO [org.flywaydb.core.internal.database.DatabaseFactory] (ServerService Thread Pool — 77) Database: jdbc:mysql://xxx.xxx.xxx.xxx:3306/jlawyerdb (MySQL 5.5)
19:15:31,542 INFO [org.flywaydb.core.internal.command.DbValidate] (ServerService Thread Pool — 77) Successfully validated 78 migrations (execution time 00:00.233s)
19:15:31,557 INFO [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Current version of schema jlawyerdb: 2.0.1.0
19:15:31,558 WARN [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Schema jlawyerdb has a version (2.0.1.0) that is newer than the latest available migration (2.0.0.4) !
19:15:31,558 WARN [org.flywaydb.core.internal.command.DbMigrate] (ServerService Thread Pool — 77) Schema jlawyerdb contains a failed future migration to version 2.0.1.0 !

Hier einmal das aktuelle Schema der security_users Tabelle:

principalId varchar(50) NO PRI NULL
password varchar(200) YES NULL
lawyer tinyint(4) YES NULL
countryCode varchar(10) YES NULL
areaCode varchar(10) YES NULL
emailAddress varchar(80) YES NULL
emailInType varchar(15) YES NULL
emailInServer varchar(80) YES NULL
emailInUser varchar(75) YES NULL
emailInPwd varchar(75) YES NULL
emailOutServer varchar(80) YES NULL
emailOutUser varchar(75) YES NULL
emailOutPwd varchar(75) YES NULL
emailSenderName varchar(150) YES NULL
emailSignature varchar(3500) YES NULL
emailInSsl tinyint(4) YES NULL
emailOutSsl tinyint(4) YES NULL
emailStartTls tinyint(4) YES NULL
settings mediumblob YES NULL
beaCertificate mediumblob YES NULL
beaCertificateAutoLogin tinyint(4) YES NULL
beaCertificatePassword varchar(50) YES NULL
emailOutPort varchar(30) YES NULL
abbreviation varchar(50) YES NULL
primary_group varchar(50) YES MUL NULL
cloudHost varchar(250) YES NULL
cloudPort int(11) NO NULL
cloudSsl tinyint(4) YES NULL
cloudUser varchar(50) YES NULL
cloudPassword varchar(50) YES NULL
cloudPath varchar(250) YES NULL
displayName varchar(250) YES NULL
voipUser varchar(100) YES NULL
voipPassword varchar(100) YES NULL
voipId varchar(50) YES NULL

Ein Start mit Version 2.0.1.0 bekräftigt die Annahme einer nicht vollständig erfolgreichen Migration. Hier starten die Fehlermeldungen mit:

18:00:41,223 INFO [org.flywaydb.core.internal.database.DatabaseFactory] (ServerService Thread Pool — 75) Database: jdbc:mysql://xxx.xxx.xxx.xxx:3306/jlawyerdb (MySQL 5.5)
18:00:41,599 ERROR [org.jlawyer.persistence.DatabaseMigrator] (ServerService Thread Pool — 75) exception caught: org.flywaydb.core.api.FlywayException: Validate failed: Detected failed migration to version 2.0.1.0 (AddVoipIdToUser)
at org.flywaydb.core.Flyway.doValidate(Flyway.java:1467)
at org.flywaydb.core.Flyway.access$100(Flyway.java:82)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1349)
at org.flywaydb.core.Flyway$1.execute(Flyway.java:1341)
at org.flywaydb.core.Flyway.execute(Flyway.java:1696)
at org.flywaydb.core.Flyway.migrate(Flyway.java:1341)
at org.jlawyer.persistence.DatabaseMigrator.integrate(DatabaseMigrator.java:732)
at org.hibernate.internal.SessionFactoryImpl.<init>(SessionFactoryImpl.java:276)
at org.hibernate.boot.internal.SessionFactoryBuilderImpl.build(SessionFactoryBuilderImpl.java:467)
at org.hibernate.jpa.boot.internal.EntityManagerFactoryBuilderImpl.build(EntityManagerFactoryBuilderImpl.java:939)
at org.jboss.as.jpa.hibernate5.TwoPhaseBootstrapImpl.build(TwoPhaseBootstrapImpl.java:44)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:170)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1$1.run(PersistenceUnitServiceImpl.java:128)
at org.wildfly.security.manager.WildFlySecurityManager.doChecked(WildFlySecurityManager.java:649)
at org.jboss.as.jpa.service.PersistenceUnitServiceImpl$1.run(PersistenceUnitServiceImpl.java:212)
at org.jboss.threads.ContextClassLoaderSavingRunnable.run(ContextClassLoaderSavingRunnable.java:35)
at org.jboss.threads.EnhancedQueueExecutor.safeRun(EnhancedQueueExecutor.java:1982)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.doRunTask(EnhancedQueueExecutor.java:1486)
at org.jboss.threads.EnhancedQueueExecutor$ThreadBody.run(EnhancedQueueExecutor.java:1377)
at java.lang.Thread.run(Thread.java:748)
at org.jboss.threads.JBossThread.run(JBossThread.java:485)

Wir wären dir für Lösungsvorschläge sehr dankbar, weil wir so mit J-Lawyer gar nicht mehr arbeiten können und dringend auf die Daten angewiesen sind.

Viele Grüße

Dirk