Hacktoberfest 2026 : les issues que les mainteneurs ont marquées pour octobre, ouvertes et accessibles aux débutants. Parcourir les issues Hacktoberfest

Unrecognized database schema version is treated as a pre-2.0 database

Fermée Adaptée aux débutants
  • Quelque chose ne va pas ?
#496 0 commentaires 0 réactions 0 personnes assignées Voir sur GitHub

Les mainteneurs répondent en général sous 1 jour

Une pull request liée a déjà été fusionnée.

  • #497 par @tonygermano — fusionnée

Évaluation

Difficulté
2/5
Temps estimé
1-3 heures
Accessibilité débutants
72/100
Type d'issue
Bug
Clarté
Clairement spécifiée
Activité
Active
Stack technique
java
Domaine
backend, databases

Piste de recherche

Commencez par lire ServerMigrator.getCurrentVersion() et migrate() ; l’issue désigne ces méthodes et la recherche de version dans SCHEMA_INFO comme chemin de l’échec. Vérifiez comment une table vide est gérée afin qu’elle démarre toujours à V0, et comment une version stockée non reconnue devrait déclencher MigrationException avant l’exécution des migrations. Le travail est terminé lorsque l’erreur indique la version stockée et qu’aucun script de migration ne s’exécute.

Rédigé par le modèle d'indexation à partir du texte de l'issue.

Description

bug

Summary

If SCHEMA_INFO holds a version string the server doesn't know, such as one written by a newer or different release, ServerMigrator treats the database as schema version 0 and starts running the legacy pre-2.0 migrations against it. Startup then fails with an error about a 2.x-era delta script, which says nothing about the real problem.

Steps to reproduce

With the default Derby database, from the server's install directory:

  1. Start a fresh install once so the database is created, then stop it (Ctrl+C once startup has finished): 
    ./oieserver
  2. With the server stopped, set a version this release doesn't know: 
    java -cp 'server-lib/database/*' org.apache.derby.tools.ij <<'EOF'
connect 'jdbc:derby:appdata/mirthdb';
UPDATE SCHEMA_INFO SET VERSION = '99.0.0';
SELECT * FROM SCHEMA_INFO;
exit;
EOF
  3. Start the server again: 
    ./oieserver

On other databases, run the same UPDATE with that database's client.

After the failed start, the process keeps running instead of exiting, which is a separate bug. Stop it with Ctrl+C. On Derby that also hangs, so you'll need kill -9.

Expected

Startup stops with an error naming the unrecognized version, and no migrations run.

Actual

ServerMigrator.migrate() starts the migration chain at V0 and runs LegacyMigrator(1), which executes the first legacy delta script (derby-0-1.sql, postgres-0-1.sql and so on). Startup fails with Failed to execute script for that file.

On a stock schema the script fails at its first statement, DROP TABLE TRANSPORT, because that table no longer exists, so nothing is changed. Nothing guards the path, though: the scripts run with auto-commit on, so if a TRANSPORT table did exist, it would be dropped and the next statements would alter existing tables (CHANNEL, or EVENT on MySQL) before anything failed.

Cause

ServerMigrator.getCurrentVersion() returns Version.fromString() of the stored value, which is null for any string not in the Version enum. migrate() uses null to mean an empty SCHEMA_INFO table and starts from Version.values()[0]. updateVersion() uses the same null to choose INSERT over UPDATE, so a migration step that did succeed would add a second row to SCHEMA_INFO instead of updating the first.

Fix

getCurrentVersion() throws a MigrationException when SCHEMA_INFO has a row whose version isn't recognized, naming the version found. An empty table still starts at V0, as before. Startup already stops on that exception before any other migration runs.

Related

  • Server process keeps running after a startup failure
  • Stopping the server after a failed startup hangs on Derby

🤖 Drafted with Claude Code

Langage dominant
Java
Étoiles
227
Forks
81
Merge moyen
3 j 6 h
PR mergées (30 j)
15

Préparer son environnement

Par où commencer

  1. Lisez l'issue en entier, puis le guide de contribution du projet.
  2. Signalez en commentaire que vous la prenez — cela évite que deux personnes fassent le même travail.
  3. Forkez le dépôt et travaillez sur une branche.
  4. Ouvrez une pull request qui référence le numéro de l'issue.

Autres issues de OpenIntegrationEngine/engine

Toutes les issues de OpenIntegrationEngine/engine

Issues similaires

Plus d'issues Java

Recevez les nouvelles issues par e-mail

Un résumé court des issues GitHub adaptées aux débutants.