71 lines
2.9 KiB
Markdown
71 lines
2.9 KiB
Markdown
# v5.2 Scraper: Wo liegen die Daten?
|
|
|
|
## Sitzung 2026-06-22 — Problem: Datenbank nicht auffindbar
|
|
|
|
### Kontext
|
|
User wollte einen konkreten Link zu einem neuen Chefkoch-Rezept (v5.2). Ich fand keine `real_recipes.jsonl`, keinen laufenden Container, keine DuckDB. Die 25k+ Rezepte waren in einer früheren Sitzung entstanden, deren Deployment-Kontext nicht mehr greifbar war.
|
|
|
|
### Gesuchte Orte (kein Treffer)
|
|
|
|
| Ort | Ergebnis | Bemerkung |
|
|
|-----|----------|-----------|
|
|
| `/tmp/*.duckdb` | — | Keine DuckDB-Datei |
|
|
| `/tmp/chefkoch-api/` | Nur `chefkoch-api` npm-Paket | Keine Daten |
|
|
| Local `~/.hermes/profiles/nutrition-coach/` | Keine `real_recipes.jsonl` | v4-Legacy-Dateien |
|
|
| Docker-Host 10.0.30.99 | Container `scraper` existiert nicht | Kein Recipe-Container läuft |
|
|
| Docker-Host 10.0.30.99 `/opt/` `/mnt/` `/srv/` | Nur `data/seafile/seadoc` | Keine Recipe-Daten |
|
|
| `~/.hermes/seafile_inventory.md` | Kein Recipe-Eintrag | Keine Seafile-Struktur |
|
|
|
|
### Schlussfolgerung
|
|
|
|
**v5.2-Daten liegen nicht auf dem aktuellen Host.** Mögliche Erklärungen:
|
|
1. Scraper lief auf einem anderen Host / in einer anderen Sitzung
|
|
2. Container wurde gelöscht / Volume war nicht persistent
|
|
3. Daten sind in Seafile / Gitea / anderem Storage abgelegt (aber nicht indexiert)
|
|
4. Testlauf war temporär (z.B. `/tmp/` ohne Persistenz)
|
|
|
|
### Erkennungs-Skript (zur Verwendung bei zukünftigen Suchen)
|
|
|
|
```bash
|
|
#!/bin/bash
|
|
# v5.2-where-is-my-data.sh
|
|
set -e
|
|
|
|
echo "=== v5.2 Daten-Suche ==="
|
|
|
|
# 1. Lokale Suche
|
|
echo "1. Lokale JSONL-Dateien..."
|
|
find / -name "real_recipes.jsonl" -type f 2>/dev/null | head -5
|
|
|
|
# 2. Container-Suche
|
|
echo "2. Docker-Container..."
|
|
docker ps -a | grep -i -E "scrap|recipe|food|chefkoch" || echo "Kein Container"
|
|
|
|
# 3. Seafile-Remote-Suche
|
|
echo "3. Seafile..."
|
|
# Via API: List library 'Casa' or 'Favorites' for recipe subdirs
|
|
|
|
# 4. JSONL-Größe check
|
|
echo "4. Falls gefunden, Größe:"
|
|
ls -lh $(find / -name "*.jsonl" -type f 2>/dev/null | head -5)
|
|
```
|
|
|
|
### Pflicht-Checkliste: v5.2 nach Deployment
|
|
|
|
Bevor man sagt „v5.2 läuft und hat N Rezepte“, muss verifiziert sein:
|
|
|
|
1. **Wo ist `real_recipes.jsonl`?** Absolute Pfad notieren.
|
|
2. **Ist der Pfad persistent?** (nicht `/tmp/`, nicht Ephemeral-Container)
|
|
3. **Ist ein Container definiert?** `docker ps -a` zeigt ihn.
|
|
4. **Cronjob / Watchdog** greift auf denselben Pfad zu wie der Scraper.
|
|
5. **Seafile-Backup** abgleichen: Liegen Rezepte auch in der Cloud?
|
|
|
|
### Übergabe-Wissen für nächste Sitzung
|
|
|
|
Wenn ein Agent gefragt wird „zeig mir ein Rezept-Link“, und `real_recipes.jsonl` nicht lokal ist:
|
|
1. NICHT raten (keine Beispiel-URLs aus der API-Doku generieren)
|
|
2. Prüfen: Container? Lokales File? Seafile?
|
|
3. Wenn nirgends: User informieren „Datenbank nicht gefunden, Scraper muss neu gestartet werden“
|
|
|
|
**Hinweis:** Die API-Doku (`chefkoch-api-v2-recipes.md`) gibt real existierende IDs, aber ohne JSONL kann ich nicht ohne Request validieren, dass ein bestimmtes Rezept wirklich gescraped wurde.
|