# co_app

## Insallation

1. Git-Repository clonen
2. 

## Entwicklungs- und Produktionsumgebung steuern (APP_ENV)
Die App unterscheidet zwischen Entwicklung und Produktion über die Umgebungsvariable APP_ENV.

### Entwicklung (lokal)
Im Terminal setzen:
```bash
export APP_ENV=dev
```
Die Variable gilt, solange das Terminal geöffnet ist.
Beim Starten der App:
```bash
streamlit run app/main.py
```
Die App erkennt automatisch den Dev-Modus.

### Produktion (Systemd-Dienst)

Für den produktiven Betrieb setzt systemd die Variable dauerhaft auf prod:
```ini
Environment=APP_ENV=prod
```
In prod-Modus laufen z. B. Logging und Pfade anders als lokal.

### systemd-Dienst einrichten
``/etc/systemd/system/myapp.service``
```ini
[Unit]
Description=MyApp Streamlit Service
After=network.target

[Service]
User=co_app
Group=co_app
WorkingDirectory=/opt/co_app
Environment=APP_ENV=prod
ExecStart=/usr/bin/python3 -m streamlit run app/main.py --server.port=8501
Restart=on-failure

[Install]
WantedBy=multi-user.target
```
**Installation & Start**
```bash
sudo systemctl daemon-reload
sudo systemctl enable co_app.service
sudo systemctl start co_app.service
```
**Logs ansehen**
Da streamlit + python ins systemd-Journal loggen:
```bash
journalctl -u co_app.service -f
```
**Wichtig**
- APP_ENV=dev → Entwicklung, lokale Logs, lokale DB
- APP_ENV=prod → Systemd-Betrieb, serverseitige Pfade, Logging ins Journal
- Die App liest die Variable mit:
```python
import os
APP_ENV = os.environ.get("APP_ENV", "dev")
```

## Database Setup & Migration Guide

Dieses Projekt verwendet SQLite für die interne App-Datenbank.
Das Schema wird vollständig über SQL-Migrationsdateien verwaltet, die automatisch in der richtigen Reihenfolge ausgeführt werden.

### Ordnerstruktur

```bash
data/             ← enthält die erzeugte SQLite-Datenbank (app.db)
migrations/       ← enthält alle SQL-Migrationsdateien
migrate.py        ← Python-Skript zum Anwenden der Migrationen
```
### Erstellen der Datenbank (Initial Setup)

```bash
python migrate.py
```
Das Skript:

1. erstellt den Ordner db/ (falls nicht vorhanden)
2. erzeugt eine neue Datei db/app.db
3. führt alle SQL-Dateien im Ordner migrations/ der Reihe nach aus
4. protokolliert die angewendeten Migrationen in der Tabelle schema_version

Danach ist die Datenbank vollständig initialisiert und einsatzbereit.

### Arbeiten mit Migrationen (Änderungen am Schema)

Änderungen an der Datenbankstruktur werden nie direkt an der DB vorgenommen.
Stattdessen erzeugst du eine neue Migrationsdatei im Ordner migrations/.

**Beispiel: neue Spalte hinzufügen**

Lege eine Datei an

```bash
touch /migrations/20250301_101500_add_last_login.sql
```
Dateiinhalt
```sql
BEGIN;

ALTER TABLE users ADD COLUMN last_login DATETIME;

INSERT INTO schema_version (version)
VALUES ('20250301_101500_add_last_login');

COMMIT;
```
Migration anwenden
```bash
python migrate.py
```
Das Skript erkennt automatisch, dass diese Migration neu ist und führt sie aus.

### Erneutes Ausführen (Updates)
Wenn eine bestehende Installation aktualisiert werden soll:
```bash
git pull
python migrate.py
```
Das Skript:

- liest die Tabelle schema_version
- führt nur Migrationen aus, die noch nicht angewendet wurden

Bestehende Strukturen bleiben unberührt.

### Entwicklungsphase: Hinweise

Solange das Projekt noch nicht produktiv genutzt wird, gilt:
- du kannst Migrationsdateien löschen/zusammenführen
- du kannst die komplette app.db jederzeit löschen
- vor dem ersten echten Deploy kannst du alle Migrationen zu einer sauberen initial.sql zusammenfassen

👉 **Nach dem ersten produktiven Einsatz** werden Migrationen nie mehr gelöscht, sondern nur ergänzt.

### Optional: DB neu erzeugen für Tests
Um eine frische Datenbank zu bekommen:
```bash
rm -f data/app.db
python migrate.py
```