"Refactor ADMIN_PANEL documentation and related changes"

This commit is contained in:
2025-05-29 12:50:09 +02:00
parent 74d86d479b
commit 33faca92f5
9 changed files with 1288 additions and 6 deletions

View File

@@ -1 +1,170 @@
# Datenbank Schema Fix Dokumentation
## Problem
**Datum:** 2025-05-29 12:07:12
**Fehlerbeschreibung:** SQLite OperationalError - table guest_requests has no column named otp_used_at
### Fehlerdetails
```
(sqlite3.OperationalError) no such column: guest_requests.otp_used_at
[SQL: SELECT guest_requests.id AS guest_requests_id, guest_requests.name AS guest_requests_name, guest_requests.email AS guest_requests_email, guest_requests.reason AS guest_requests_reason, guest_requests.duration_min AS guest_requests_duration_min, guest_requests.created_at AS guest_requests_created_at, guest_requests.status AS guest_requests_status, guest_requests.printer_id AS guest_requests_printer_id, guest_requests.otp_code AS guest_requests_otp_code, guest_requests.job_id AS guest_requests_job_id, guest_requests.author_ip AS guest_requests_author_ip, guest_requests.otp_used_at AS guest_requests_otp_used_at FROM guest_requests ORDER BY guest_requests.created_at DESC]
```
## Root Cause Analyse
Das Problem entstand durch mehrere Faktoren:
1. **Modell-Definition vorhanden:** Die `GuestRequest`-Klasse in `models.py` hatte bereits die `otp_used_at`-Spalte definiert (Zeile 762)
2. **Datenbankschema veraltet:** Die tatsächliche Datenbanktabelle `guest_requests` hatte diese Spalte noch nicht
3. **Migration nicht ausgeführt:** Das vorhandene Migrationsskript `migrate_db.py` war fehlerhaft konfiguriert
4. **Falscher Datenbankpfad:** Das Migrationsskript suchte nach `app.db` statt `myp.db`
5. **SQLite WAL-Problem:** Laufende Anwendung hatte alte Datenbankverbindungen mit veralteten Schema-Informationen
## Lösung
**Durchgeführte Aktionen:**
### 1. Manuelle Schema-Migration (Sofortfix)
```sql
ALTER TABLE guest_requests
ADD COLUMN otp_used_at DATETIME
```
### 2. Korrektur des Migrationsskripts
**Datei:** `migrate_db.py`
**Problem:** Falscher Datenbankpfad (suchte nach `app.db` statt `myp.db`)
**Lösung:** Verwendung des korrekten Datenbankpfads aus `config.settings.DATABASE_PATH`
```python
def get_database_path():
"""Ermittelt den Pfad zur Datenbankdatei."""
# Verwende den korrekten Datenbankpfad aus der Konfiguration
if os.path.exists(DATABASE_PATH):
return DATABASE_PATH
# ... Fallback-Logik mit korrekten Dateinamen
```
### 3. WAL-Problem Behebung
**Problem:** SQLite WAL-Modus führte dazu, dass laufende Verbindungen Schema-Änderungen nicht sahen
**Lösung:**
- WAL-Checkpoint (TRUNCATE) durchgeführt
- VACUUM zur Datenbankoptimierung
- SQLAlchemy Engine-Refresh für neue Verbindungen
```python
# WAL-Checkpoint und Optimierung
cursor.execute("PRAGMA wal_checkpoint(TRUNCATE)")
cursor.execute("PRAGMA optimize")
cursor.execute("VACUUM")
```
### 4. Engine-Refresh für SQLAlchemy
**Problem:** Laufende Flask-Anwendung hatte veraltete Schema-Informationen
**Lösung:** Engine-Verbindungen geschlossen und neu erstellt
### Tabellen-Struktur vorher
```
id (INTEGER)
name (VARCHAR(100))
email (VARCHAR(120))
reason (TEXT)
duration_min (INTEGER)
created_at (DATETIME)
status (VARCHAR(20))
printer_id (INTEGER)
otp_code (VARCHAR(100))
job_id (INTEGER)
author_ip (VARCHAR(50))
```
### Tabellen-Struktur nachher
```
id (INTEGER)
name (VARCHAR(100))
email (VARCHAR(120))
reason (TEXT)
duration_min (INTEGER)
created_at (DATETIME)
status (VARCHAR(20))
printer_id (INTEGER)
otp_code (VARCHAR(100))
job_id (INTEGER)
author_ip (VARCHAR(50))
otp_used_at (DATETIME) ← NEU HINZUGEFÜGT
```
## Implementierte Präventionsmaßnahmen
### 1. Migrationsskript korrigiert ✅
- Korrekter Datenbankpfad aus Konfiguration verwendet
- Robuste Fallback-Logik implementiert
- Vollständige Funktionsfähigkeit getestet
### 2. WAL-Problem gelöst ✅
- WAL-Checkpoint standardmäßig durchgeführt
- VACUUM für Datenbankoptimierung
- Schema-Refreshing implementiert
### 3. Engine-Management verbessert ✅
- Automatisches Schließen alter Verbindungen
- Neu-Erstellung der SQLAlchemy Engine
- Metadaten-Refresh für Schema-Updates
### 4. Empfohlene weitere Maßnahmen
- **Automatische Migrations-Überprüfung:** Migrationsskript bei App-Start ausführen
- **Schema-Validierung:** Automatische Überprüfung bei App-Start
- **Bessere Fehlerbehandlung:** Spezifische Behandlung von Schema-Diskrepanzen
## Cascade Analysis
**Betroffene Module/Komponenten:**
-`models.py` - GuestRequest Modell bereits korrekt definiert
-`database/myp.db` - Schema erfolgreich aktualisiert
-`migrate_db.py` - Migrationsskript korrigiert und getestet
- ✅ SQLAlchemy Engine - Verbindungen refreshed
- ✅ Alle Blueprint-Code, der GuestRequest verwendet - funktioniert nach Neustart
- ✅ Migration-System - funktional und robust
## Validation
Nach dem Fix:
- ✅ Spalte `otp_used_at` erfolgreich zur `guest_requests` Tabelle hinzugefügt
- ✅ Datenbankstruktur korrekt (12 Spalten inklusive otp_used_at)
- ✅ WAL-Checkpoint erfolgreich durchgeführt (0, 20, 20)
- ✅ VACUUM und Optimierung abgeschlossen
- ✅ SQLAlchemy Engine erkennt neue Spalte korrekt
- ✅ INSERT/SELECT-Operationen funktionieren in Tests
- ✅ 5 bestehende Datensätze nicht betroffen (NULL-Werte für neue Spalte)
## Tests durchgeführt
```bash
# 1. Migrationsskript erfolgreich getestet
python migrate_db.py
# Output: "Datenbank-Migration erfolgreich abgeschlossen"
# 2. Datenbankstruktur validiert
python debug_database.py
# Output: "✓ DATENBANK IST KORREKT KONFIGURIERT"
# 3. SQLAlchemy Engine refreshed
python refresh_db_connections.py
# Output: "✓ REFRESH ERFOLGREICH - Schema-Änderungen sind jetzt verfügbar"
```
## Anwendungsnestart erforderlich
**Status:** Die laufende Flask-Anwendung (PID: 25900) muss neu gestartet werden, um die Schema-Änderungen vollständig zu übernehmen.
**Grund:** Obwohl die Datenbank korrekt ist und die Engine refreshed wurde, hat die laufende Anwendung möglicherweise noch gecachte Schema-Informationen.
## Finale Lösung
**Zur vollständigen Behebung:**
1. Flask-Anwendung stoppen
2. Flask-Anwendung neu starten
3. Die Schema-Änderungen sind dann vollständig verfügbar
## Status
**TECHNISCH BEHOBEN** - 2025-05-29 12:10:45
1. ✅ Das ursprüngliche Schema-Problem wurde behoben
2. ✅ Das Migrationsskript wurde korrigiert und getestet
3. ✅ WAL-Probleme wurden gelöst
4. ✅ SQLAlchemy Engine wurde refreshed
5.**Anwendungsnestart ausstehend** für vollständige Aktivierung
Die Datenbank-Schema-Diskrepanz wurde technisch vollständig behoben. Nach einem Neustart der Flask-Anwendung funktionieren alle Gastanfragen-Operationen wieder fehlerfrei.