Nicolas Fryder
f145188d1f
bands.ma_id est BIGINT (crawler génère jusqu'à ~3.5e9) mais band_locations.ma_id avait été créé en INTEGER (max 2.1e9). Tout INSERT pour un band à ma_id élevé échouait en "integer out of range", erreur avalée silencieusement par l'enqueue. 62 239 bands (sur 96 143 localisables) n'entraient donc jamais dans le pipeline, d'où 0 llm_needed / 0 erreur trompeurs. - migration 008: ma_id BIGINT (installs neuves) - migration 009: ALTER COLUMN ma_id TYPE BIGINT (DB existante) - enqueue.py: compte les inserts échoués (failed=) au lieu de les avaler - worker.py: sync_bands_primary prend le lieu d'ORIGINE (step 0) et non la dernière localisation — garde les groupes européens en Europe - admin app.js: coût LLM robuste au NaN (NUMERIC accepte la valeur spéciale NaN) Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
9 lines
452 B
SQL
9 lines
452 B
SQL
-- 009_band_locations_bigint.sql
|
|
-- bands.ma_id est BIGINT (valeurs jusqu'à ~3.5e9 côté crawler), mais
|
|
-- band_locations.ma_id avait été créé en INTEGER (008). Tout INSERT pour un
|
|
-- band avec ma_id > 2147483647 échouait en "integer out of range" — l'erreur
|
|
-- était avalée silencieusement par l'enqueue, laissant ~62k bands hors pipeline.
|
|
-- On aligne le type sur bands.ma_id.
|
|
|
|
ALTER TABLE band_locations
|
|
ALTER COLUMN ma_id TYPE BIGINT;
|