"Refactor ADMIN_PANEL documentation and related changes"
This commit is contained in:
@@ -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.
|
Reference in New Issue
Block a user