2026-09-07 12:40:12 +02:00
2026-09-07 12:40:12 +02:00
2026-09-07 12:25:07 +02:00
2026-09-07 12:25:07 +02:00
2026-09-07 12:25:07 +02:00
2026-09-07 12:25:07 +02:00
2026-09-07 12:25:07 +02:00
2026-09-07 12:40:02 +02:00
2026-09-07 12:25:07 +02:00

Wurzelwerk — Phase 2: Aufbereitung

Reichert raw_items deterministisch an: Dubletten, Akteure, Orte, Tonalität, Embeddings. Kein LLM, kein Sampling, keine Netzabfrage zur Laufzeit — das Ergebnis hängt allein an der Eingabe und der coder_version.

Setzt das Ingest-Schema aus swp-01-ingest voraus und schreibt ausschließlich nach codings. raw_items bleibt unberührt.

Spezifikation: phase_02_spec.md.

Dateien

Datei Zweck
phase_02_spec.md Spezifikation der fünf Module und ihrer Abnahmekriterien
migrations/ Schemaänderungen, aufsteigend anzuwenden
db.py Auflösung von DATABASE_URL, Verbindung
check_db.py Rauchtest: Anmeldung, Bestand, fehlende Voraussetzungen

Einrichtung

python3 -m venv .venv
.venv/bin/pip install -r requirements.txt
cp .env.example .env && chmod 600 .env && $EDITOR .env
.venv/bin/python check_db.py

Migrationen

Aufsteigend anwenden, auf Dev und Prod dieselben Dateien in derselben Reihenfolge. Welche schon liefen, steht in schema_migrationen:

psql "$ADMIN_DATABASE_URL" -v ON_ERROR_STOP=1 -f migrations/p2-000-migrationsbuch.sql
psql "$ADMIN_DATABASE_URL" -v ON_ERROR_STOP=1 -f migrations/p2-001-codings-mehrschichtig.sql

# Stand abfragen
psql "$DATABASE_URL" -c 'select name, angewandt_am from schema_migrationen order by name'

Die Zählung trägt das Präfix p2-, weil die Ingest-Migrationen eine eigene haben und beide auf dieselbe Datenbank laufen.

Migrationen brauchen einen anderen Zugang als der Betrieb. Die Tabellen gehören postgres, nicht wurzelwerk; alter table scheitert sonst mit must be owner of table codings. Im Dev-Container:

podman exec -i postgres psql -U postgres -d wurzelwerk -v ON_ERROR_STOP=1 -f - < migrations/p2-001-codings-mehrschichtig.sql

Dass die Anwendungsrolle ihr eigenes Schema nicht besitzt, ist eine offene Frage — entweder bleibt es so und Migrationen laufen als Administrator, oder die Tabellen wechseln per alter table … owner to wurzelwerk den Besitzer.

Voraussetzungen an die Datenbank

pgvector fehlt im Image postgres:latest: select * from pg_available_extensions where name = 'vector' bleibt leer, create extension vector scheitert. Ohne sie kein item_embeddings. Das ist ein Image-Tausch auf pgvector/pgvector:pg18, keine Migration. Die vier übrigen Module laufen ohne.

Grenzen des Datensatzes

Volltext liefert nur ein Teil der Quellen — Ingest liest RSS, und viele Häuser geben dort keinen content:encoded heraus (Stand 7.9.2026: faz 311/489, heise 174/196, aber derstandard, welt, dlf, taz, sz jeweils 0). Das ist keine Lücke, die sich schließen lässt, sondern eine Eigenschaft der Quellen. Module müssen auf Titel und Teaser allein tragfähig bleiben und dürfen die Vergleichsbasis nicht davon abhängig machen, ob ein Item zufällig Volltext hat.

S
Description
No description provided
Readme
496 KiB
Languages
Python 87.7%
PLpgSQL 10.9%
Dockerfile 1.4%