Projekt

Allgemein

Profil

Aktionen

Feature #128

geschlossen
JH

Datenbankversion aus dem Namen der neuesten Migration ableiten, Konstante DBVersion entfällt

Feature #128: Datenbankversion aus dem Namen der neuesten Migration ableiten, Konstante DBVersion entfällt

Von Julius Haman vor 9 Tagen hinzugefügt. Vor 9 Tagen aktualisiert.

Status:
Erledigt
Priorität:
Normal
Zugewiesen an:
-
Zielversion:
Beginn:
Abgabedatum:
% erledigt:

0%

Geschätzter Aufwand:
Gefunden in Version:

Beschreibung

Die Soll-Version der Datenbank (ModelVersion) kommt heute aus der von Hand gepflegten Konstante AssemblyConstants.DBVersion und steht zusätzlich im Namen der EF-Migration (Version3140). Das ist redundant: Wer eine Migration anlegt, muss die Konstante mitziehen, und wer sie vergisst, bekommt eine Abweichung (der Kommentar in MigrationService warnt selbst davor). Außerdem ist die Namensgebung nicht durchgängig versionskodiert (z.B. RemoveGearshifter).

Ziel

Die Modellversion wird aus dem Namen der neuesten Migration abgeleitet. Die Konstante DBVersion entfällt, es gibt nur noch eine Quelle.

Lösungsansatz

  • Migrationen heißen ab 3.1.4.0 Version_a_b_c_d (Klassennamen dürfen keine Punkte enthalten, die Unterstriche trennen die Segmente eindeutig, auch bei mehrstelligen Segmenten wie 3.1.10.0). Aufruf: dotnet ef migrations add Version_3_1_5_0.
  • Version3140 ist noch unveröffentlicht und wird in Version_3_1_4_0 umbenannt (Klasse, Dateien, Designer, Migrationsattribut, Testklasse Version3140MigrationTests). Bereits veröffentlichte Migrationen werden nicht angefasst: Ihre IDs stehen in der __EFMigrationsHistory der Nutzer-Datenbanken.
  • EcContext.ModelVersion liest die Version aus dem Namen der neuesten Migration (Reflection über die Migration-Typen des Model-Assemblys, kein Datenbankzugriff).
  • About-Fenster nutzt ModelVersion statt der Konstante.
  • Test, der sicherstellt, dass die neueste Migration dem Muster Version_a_b_c_d entspricht (sonst fällt ein falsch benannte Migration erst beim Start auf).

Unverändert

  • Der Eintrag Database|Version in der Tabelle Preferences jeder Datenbank bleibt die Ist-Version der Datei. Er wird weiter gebraucht für die Legacy-Erkennung (2.2.3.53), den Schutz vor einer neueren Datenbank und die Anzeige.
  • Eine Migration pro Release bleibt die Konvention; innerhalb einer Version werden Änderungen in die Migration gefaltet.

Hinweis

  • Zeitpunkt: erst nach einem Test mit echter Fahrt (#127) und eigener Commit, damit die Versionslogik beim Start nicht kurz vor dem Release von 3.1.4 geändert wird.

JH Von Julius Haman vor 9 Tagen aktualisiert Aktionen #1

Hinweis zur SQL-Anpassung von Entwicklungs-Datenbanken gestrichen (es gibt keine zu erhaltende Entwicklungs-DB).

JH Von Julius Haman vor 9 Tagen aktualisiert Aktionen #2

  • Zielversion wurde auf ErControl 3.1.4 gesetzt

JH Von Julius Haman vor 9 Tagen aktualisiert Aktionen #3

  • Status wurde von Neu zu Erledigt geändert

Umgesetzt: Die Modellversion wird aus dem Namen der neuesten Migration abgeleitet (DatabaseModelVersion), die Konstante DBVersion entfällt, Version3140 heißt jetzt Version_3_1_4_0. Test für die Namensregel ergänzt.

Aktionen

Auch abrufbar als: PDF Atom