Schlaf-CSV: Legacy Apple-Aggregat → Vorlagen-Mapping + Data Layer (ARCH §8) #69

New Issue

Lars · 2026-04-10T09:29:22+02:00

Lars commented

2026-04-10 09:29:22 +02:00

Ziel

Schlaf-Import von quellenspezifischem Apple-Aggregat-Parser (import_mode: apple_sleep_aggregate, csv_parser/sleep_apple_import.py) auf einen Weg bringen, der der Architektur-Leitlinie entspricht:

Import (Ingest): Zuordnung + Typ-/Einheits-Konvertierung; keine versteckte Fach-Interpretation.
Auswertung / Ableitung: Issue #53 Data Layer (Layer 1+), siehe docs/issues/issue-53-phase-0c-multi-layer-architecture.md.

Verbindliche Einordnung: .claude/rules/ARCHITECTURE.md Abschnitt 8.

Motivation

Andere Schlaf-Exports (Spalten, Hersteller) sollen ohne neuen Sonderparser integrierbar sein.
Transparenz: sichtbares Zielfeldmodell (Import-Objekt / sleep_log-Felder), direct vs. später in Layer 1 abgeleitet klar trennbar.
Langfristig: eine CSV kann mehrere Zieltabellen speisen — einheitliche Pipeline statt paralleler Logikpfade.

Grober Scope (Übergang)

csv_parser / module_registry: Schlaf-Zielfelder definieren, die direkt aus einer CSV-Zeile pro Nacht befüllbar sind; optional import_mode z. B. row_mapped vs. deprecates apple_sleep_aggregate.
Executor: Zeilenimport wie bei anderen Modulen (nach Mapping + type_conversions); Duplikatstrategie an sleep_log (z. B. (profile_id, date)).
Apple-Schlaf: entweder als Vorlage mit Mapping auf dieselben Felder ODER Rohdaten-Staging (JSONB/Zusatzspalte), dann Layer 1 füllt kanonische Sicht — im Issue konkret festlegen.
Router: /api/sleep/import/apple-health und Universal-Import konsolidieren oder dokumentiert deprecaten.
Tests: pytest (Smoke + mindestens eine echte Schlafanalyse-CSV); Regression bestehender Nutzerdaten.
Doku: Issue #21 / CSV-Vorlagen-Admin; Migration-Hinweise falls Schema erweitert.

Akzeptanz (Vorschlag)

Neue Apple-„Schlafanalyse“-Datei importierbar ohne ausschließlich sleep_apple_import-Pfad ODER klar dokumentierter Übergang mit Enddatum.
Admin: Vorlagen für Schlaf zeigen Zielfelder (kein „nur ignorieren“ ohne Erklärung).
Keine neuen schweren semantischen Berechnungen ausschließlich beim Insert; was interpretiert wird, ist Data Layer zugeordnet oder explizit als „Staging“ beschriftet.

Referenzen

ARCHITECTURE §8 (Import vs. Data Layer)
Issue #53 (Multi-Layer)
Issue #21 (Universal CSV / Vorlagen)
Bestand: backend/csv_parser/sleep_apple_import.py, backend/routers/sleep.py, sleep_log-Schema (009_sleep_log.sql)

Aufwand (grobe Schätzung)

8–16 h (abhängig von Staging vs. nur direktes Mapping)

## Ziel Schlaf-Import von **quellenspezifischem Apple-Aggregat-Parser** (`import_mode: apple_sleep_aggregate`, `csv_parser/sleep_apple_import.py`) auf einen Weg bringen, der der Architektur-Leitlinie entspricht: - **Import (Ingest):** Zuordnung + **Typ-/Einheits-Konvertierung**; keine versteckte Fach-Interpretation. - **Auswertung / Ableitung:** **Issue #53 Data Layer** (Layer 1+), siehe `docs/issues/issue-53-phase-0c-multi-layer-architecture.md`. Verbindliche Einordnung: `.claude/rules/ARCHITECTURE.md` **Abschnitt 8**. ## Motivation - Andere Schlaf-Exports (Spalten, Hersteller) sollen ohne neuen Sonderparser integrierbar sein. - Transparenz: sichtbares Zielfeldmodell (Import-Objekt / `sleep_log`-Felder), **direct vs. später in Layer 1 abgeleitet** klar trennbar. - Langfristig: eine CSV kann mehrere Zieltabellen speisen — einheitliche Pipeline statt paralleler Logikpfade. ## Grober Scope (Übergang) 1. **`csv_parser` / `module_registry`:** Schlaf-Ziel**felder** definieren, die **direkt** aus einer CSV-Zeile pro Nacht befüllbar sind; optional `import_mode` z. B. `row_mapped` vs. deprecates `apple_sleep_aggregate`. 2. **Executor:** Zeilenimport wie bei anderen Modulen (nach Mapping + `type_conversions`); Duplikatstrategie an `sleep_log` (z. B. `(profile_id, date)`). 3. **Apple-Schlaf:** entweder als **Vorlage mit Mapping** auf dieselben Felder ODER Rohdaten-Staging (JSONB/Zusatzspalte), dann Layer 1 füllt kanonische Sicht — im Issue konkret festlegen. 4. **Router:** `/api/sleep/import/apple-health` und Universal-Import konsolidieren oder dokumentiert deprecaten. 5. **Tests:** pytest (Smoke + mindestens eine echte Schlafanalyse-CSV); Regression bestehender Nutzerdaten. 6. **Doku:** Issue #21 / CSV-Vorlagen-Admin; Migration-Hinweise falls Schema erweitert. ## Akzeptanz (Vorschlag) - Neue Apple-„Schlafanalyse“-Datei importierbar **ohne** ausschließlich `sleep_apple_import`-Pfad ODER klar dokumentierter Übergang mit Enddatum. - Admin: Vorlagen für Schlaf zeigen **Zielfelder** (kein „nur ignorieren“ ohne Erklärung). - Keine neuen schweren semantischen Berechnungen ausschließlich beim Insert; was interpretiert wird, ist **Data Layer** zugeordnet oder explizit als „Staging“ beschriftet. ## Referenzen - ARCHITECTURE §8 (Import vs. Data Layer) - Issue #53 (Multi-Layer) - Issue #21 (Universal CSV / Vorlagen) - Bestand: `backend/csv_parser/sleep_apple_import.py`, `backend/routers/sleep.py`, `sleep_log`-Schema (`009_sleep_log.sql`) ## Aufwand (grobe Schätzung) 8–16 h (abhängig von Staging vs. nur direktes Mapping)

Sign in to join this conversation.