Hetzner-Backup/REFACTORING_ISSUES.md

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