87 Zeilen
2.8 KiB
Markdown
87 Zeilen
2.8 KiB
Markdown
# Refactoring Issues - Blueprint Migration
|
|
|
|
## Zusammenfassung
|
|
|
|
Die Blueprint-Migration wurde zurückgesetzt, da sie zu viele Breaking Changes verursachte.
|
|
|
|
## Identifizierte Probleme
|
|
|
|
### 1. Schema-Inkonsistenzen
|
|
Die Blueprint-Code geht von einem anderen Datenbankschema aus als tatsächlich existiert:
|
|
|
|
#### Sessions-Tabelle
|
|
**Erwartet von Blueprints:**
|
|
- `license_key` (direkte Spalte)
|
|
- `username`
|
|
- `computer_name`
|
|
- `hardware_id`
|
|
- `device_id`
|
|
- `app_version`
|
|
- `active` (statt `is_active`)
|
|
- `login_time` (statt `started_at`)
|
|
- `logout_time` (statt `ended_at`)
|
|
- `last_activity` (statt `last_heartbeat`)
|
|
|
|
**Tatsächliches Schema:**
|
|
- `license_id` (Foreign Key zu licenses)
|
|
- `session_id`
|
|
- `ip_address`
|
|
- `user_agent`
|
|
- `started_at`
|
|
- `last_heartbeat`
|
|
- `ended_at`
|
|
- `is_active`
|
|
|
|
### 2. Falsche SQL-JOINs
|
|
Über 20+ falsche JOINs in verschiedenen Blueprint-Dateien:
|
|
- Falsch: `JOIN sessions s ON l.license_key = s.license_key`
|
|
- Richtig: `JOIN sessions s ON l.id = s.license_id`
|
|
|
|
Betroffene Dateien:
|
|
- `export_routes.py` (5 Stellen)
|
|
- `api_routes.py` (4 Stellen)
|
|
- `session_routes.py` (6 Stellen)
|
|
- `customer_routes.py` (2 Stellen)
|
|
|
|
### 3. Fehlende Funktionen
|
|
- `models.py`: 5 Funktionen fehlten
|
|
- `utils/export.py`: `create_batch_export()` fehlte
|
|
|
|
## Empfohlenes Vorgehen
|
|
|
|
### Option 1: Schrittweise Migration (Empfohlen)
|
|
1. **Schema-Analyse**: Vollständige Dokumentation des aktuellen DB-Schemas
|
|
2. **Blueprint-Anpassung**: Code an tatsächliches Schema anpassen
|
|
3. **Test-Suite**: Umfassende Tests vor Migration schreiben
|
|
4. **Einzelne Blueprints**: Einen Blueprint nach dem anderen migrieren
|
|
|
|
### Option 2: Schema-Anpassung
|
|
1. **Neue Spalten**: Alle erwarteten Spalten zur DB hinzufügen
|
|
2. **Daten-Migration**: Bestehende Daten migrieren
|
|
3. **Kompatibilitäts-Layer**: Views oder Trigger für Rückwärtskompatibilität
|
|
|
|
### Option 3: Neu-Implementation
|
|
1. **Sauberer Schnitt**: Blueprints von Grund auf neu schreiben
|
|
2. **Aktuelles Schema**: Code basierend auf tatsächlichem Schema
|
|
3. **Keine Assumptions**: Jede Spalte explizit prüfen
|
|
|
|
## Lessons Learned
|
|
|
|
1. **Keine Annahmen über Schema**: Immer das tatsächliche Schema prüfen
|
|
2. **Inkrementelle Migration**: Große Refactorings in kleine Schritte aufteilen
|
|
3. **Tests zuerst**: Umfassende Tests vor strukturellen Änderungen
|
|
4. **Rollback-Plan**: Immer Backups vor größeren Änderungen
|
|
|
|
## Aktueller Status
|
|
|
|
- ✅ Anwendung läuft wieder mit ursprünglichem Code
|
|
- ✅ Alle Funktionen sind wiederhergestellt
|
|
- ⚠️ Blueprint-Migration wurde zurückgesetzt
|
|
- 📋 Detaillierte Problembeschreibung für zukünftige Versuche dokumentiert
|
|
|
|
## Nächste Schritte
|
|
|
|
1. Vollständige Schema-Dokumentation erstellen
|
|
2. Test-Suite für aktuelle Funktionalität schreiben
|
|
3. Migration in kleineren, testbaren Schritten planen
|
|
4. Jeden Blueprint einzeln mit Tests migrieren |