DB-Migration: fallbackToDestructiveMigration() entfernen & Migrationsstrategie einführen #89

New issue

Closed

opened 2026-05-17 09:14:22 +00:00 by jreinemann-euris · 1 comment

jreinemann-euris commented

2026-05-17 09:14:22 +00:00

(Migrated from github.com)

Problem

fallbackToDestructiveMigration() in der Room-Datenbank-Konfiguration löscht bei jedem Schema-Wechsel alle Benutzerdaten. Das war akzeptabel während der frühen Entwicklung, muss aber entfernt werden, bevor echte Nutzerdaten entstehen.

Ziel

fallbackToDestructiveMigration() aus der Room-Konfiguration entfernen
Eine Migrationsstrategie auswählen und implementieren, sodass zukünftige Schema-Änderungen datenerhaltend ablaufen

Vorgehen (tech-decision → Implementierung)

Dieser Ticket-Typ ist tech-decision: Copilot stellt die Migrationsoptionen vor, der User wählt aus, dann wird implementiert.

Zu bewertende Strategien

#	Ansatz	Beschreibung
A	Manuelle Room-Migrations	Für jede Schema-Änderung wird ein `Migration(from, to)`-Objekt geschrieben (SQL-Statements). Standard-Ansatz.
B	Auto-Migration (Room 2.4+)	Room generiert Migrations-SQL automatisch, solange nur additive Änderungen (neue Spalten/Tabellen) vorgenommen werden. Breaking changes erfordern weiterhin manuelle Migrationen.
C	Hybrid	Auto-Migration als Default, manuelle Migration für Breaking changes (Umbenennungen, Typ-Änderungen, Spalten-Löschungen).

Akzeptanzkriterien

fallbackToDestructiveMigration() ist entfernt
Gewählte Migrationsstrategie ist dokumentiert (kurzer Kommentar in der DB-Konfiguration)
Mindestens eine Beispiel-Migration existiert (für die aktuelle Schema-Version als Baseline)
Alle bestehenden Unit- und Instrumentierungstests laufen weiterhin grün
Für zukünftige Schema-Änderungen gilt: MigrationTest (Room MigrationTestHelper) ist eingerichtet

Technischer Kontext

Room-Konfiguration: app/src/main/…/data/db/KrisenvorratDatabase.kt
Aktuelle DB-Version: siehe @Database(version = …)
fallbackToDestructiveMigration() wurde mit Commit "refactor: kcal/100g → kcal/kg" eingeführt

## Problem `fallbackToDestructiveMigration()` in der Room-Datenbank-Konfiguration löscht bei jedem Schema-Wechsel alle Benutzerdaten. Das war akzeptabel während der frühen Entwicklung, muss aber entfernt werden, bevor echte Nutzerdaten entstehen. ## Ziel 1. `fallbackToDestructiveMigration()` aus der Room-Konfiguration entfernen 2. Eine Migrationsstrategie auswählen und implementieren, sodass zukünftige Schema-Änderungen datenerhaltend ablaufen ## Vorgehen (tech-decision → Implementierung) Dieser Ticket-Typ ist `tech-decision`: Copilot stellt die Migrationsoptionen vor, der User wählt aus, dann wird implementiert. ### Zu bewertende Strategien | # | Ansatz | Beschreibung | |---|--------|--------------| | A | **Manuelle Room-Migrations** | Für jede Schema-Änderung wird ein `Migration(from, to)`-Objekt geschrieben (SQL-Statements). Standard-Ansatz. | | B | **Auto-Migration (Room 2.4+)** | Room generiert Migrations-SQL automatisch, solange nur additive Änderungen (neue Spalten/Tabellen) vorgenommen werden. Breaking changes erfordern weiterhin manuelle Migrationen. | | C | **Hybrid** | Auto-Migration als Default, manuelle Migration für Breaking changes (Umbenennungen, Typ-Änderungen, Spalten-Löschungen). | ### Akzeptanzkriterien - [ ] `fallbackToDestructiveMigration()` ist entfernt - [ ] Gewählte Migrationsstrategie ist dokumentiert (kurzer Kommentar in der DB-Konfiguration) - [ ] Mindestens eine Beispiel-Migration existiert (für die aktuelle Schema-Version als Baseline) - [ ] Alle bestehenden Unit- und Instrumentierungstests laufen weiterhin grün - [ ] Für zukünftige Schema-Änderungen gilt: MigrationTest (Room `MigrationTestHelper`) ist eingerichtet ## Technischer Kontext - Room-Konfiguration: `app/src/main/…/data/db/KrisenvorratDatabase.kt` - Aktuelle DB-Version: siehe `@Database(version = …)` - `fallbackToDestructiveMigration()` wurde mit Commit *"refactor: kcal/100g → kcal/kg"* eingeführt

jreinemann-euris commented

2026-05-17 09:43:33 +00:00

(Migrated from github.com)

Umgesetzt: Room AutoMigration als Strategie. Manuelle Migrationen (v1-v5) entfernt, DB auf v6 (Clean-Slate). fallbackToDestructiveMigration() als Fallback aktiv. Dokumentation aktualisiert.

No milestone

No project

No assignees

1 participant

Notifications

Due date

The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: bollwerkadmin/bollwerk#89

No description provided.