-- =============================================================================
-- 01_ttl_adjustments.sql — Ajustement des TTL de rétention des logs
--
-- Objectif :
--   - http_logs      : conserver 30 jours (était 7 jours)
--   - http_logs_raw  : supprimer au plus vite (2 heures, était 1 jour)
--
-- Usage (déploiements existants) :
--   clickhouse-client --multiquery < sql/migrations/01_ttl_adjustments.sql
--
-- IMPORTANT — http_logs_raw (partition) :
--   La modification du TTL ci-dessous s'applique immédiatement aux nouvelles
--   insertions. Toutefois, la PARTITION BY (toDate → toStartOfHour) ne peut
--   PAS être modifiée via ALTER TABLE — elle est fixée à la création.
--
--   Pour adopter la partition horaire sur un déploiement existant, procéder
--   manuellement :
--     1. CREATE TABLE ja4_logs.http_logs_raw_new ( ... identique à init.sql ... )
--     2. Attendre que http_logs_raw soit vide (ou accepter la perte des raw non traités)
--     3. DROP VIEW IF EXISTS ja4_logs.mv_http_logs
--     4. DROP TABLE ja4_logs.http_logs_raw
--     5. RENAME TABLE ja4_logs.http_logs_raw_new TO ja4_logs.http_logs_raw
--     6. Recréer mv_http_logs (cf. init.sql)
--
--   Si la migration complète n'est pas possible, la modification du TTL seul
--   (ci-dessous) ramène la suppression à : fin de la partition quotidienne + 2h,
--   soit au plus 26h au lieu de 48h — amélioration immédiate sans downtime.
-- =============================================================================

-- -----------------------------------------------------------------------------
-- 1. http_logs — rétention étendue à 30 jours
-- -----------------------------------------------------------------------------
ALTER TABLE ja4_logs.http_logs
    MODIFY TTL log_date + INTERVAL 30 DAY;

-- -----------------------------------------------------------------------------
-- 2. http_logs_raw — TTL réduit à 2 heures
--    (la MV traite les données de façon synchrone à l'INSERT, donc les raw
--    sont redondants dès leur insertion)
-- -----------------------------------------------------------------------------
ALTER TABLE ja4_logs.http_logs_raw
    MODIFY TTL ingest_time + INTERVAL 2 HOUR;

-- -----------------------------------------------------------------------------
-- Vérifications post-migration
-- -----------------------------------------------------------------------------
-- SELECT engine_full FROM system.tables
--   WHERE database IN ('ja4_logs', 'ja4_processing') AND name IN ('http_logs', 'http_logs_raw');

-- =============================================================================
-- Ajustements TTL des tables de MVs (bot_detector) — 7 jours max
-- =============================================================================

-- agg_host_ip_ja4_1h — TTL 7 jours (était : aucun)
-- Note : PARTITION BY ne peut pas être ajouté via ALTER TABLE.
--   Pour la partition quotidienne (recommandée), recréer la table via deploy_views.sql.
--   Sans partition explicite, ClickHouse applique le TTL par granule (moins efficace).
ALTER TABLE ja4_processing.agg_host_ip_ja4_1h
    MODIFY TTL window_start + INTERVAL 7 DAY;

-- agg_header_fingerprint_1h — TTL 7 jours (était : aucun)
ALTER TABLE ja4_processing.agg_header_fingerprint_1h
    MODIFY TTL window_start + INTERVAL 7 DAY;

-- ml_detected_anomalies — TTL 7 jours (était 30 jours, déjà corrigé en 7j pour certains)
-- Note : MODIFY ORDER BY (src_ip, ja4, host, model_name) ne peut PAS être appliqué
-- sur ClickHouse 24.8 car ja4/host sont des colonnes existantes (erreur BAD_ARGUMENTS 36).
-- Le correctif est dans le schéma de base (06_ml_tables.sql) — ORDER BY corrigé à la
-- création. Pour les déploiements existants avec l'ancien ORDER BY, recréer la table.
ALTER TABLE ja4_processing.ml_detected_anomalies
    MODIFY TTL detected_at + INTERVAL 7 DAY;

-- ml_all_scores — TTL 7 jours (était 3 jours)
-- Note : PARTITION BY ne peut pas être ajouté via ALTER TABLE.
--   Pour la partition quotidienne (recommandée), recréer la table via deploy_views.sql.
ALTER TABLE ja4_processing.ml_all_scores
    MODIFY TTL window_start + INTERVAL 7 DAY;

-- =============================================================================
-- Vues dashboard — suppression des vues inutilisées, ajout des vues manquantes
-- Ces vues n'ont pas d'état persistant : les DROP/CREATE sont idempotents.
-- =============================================================================
-- Supprimer les vues inutilisées (non référencées par les routes Python)
DROP VIEW IF EXISTS ja4_processing.view_dashboard_summary;
DROP VIEW IF EXISTS ja4_processing.view_dashboard_timeseries;
DROP VIEW IF EXISTS ja4_processing.view_dashboard_threat_dist;
DROP VIEW IF EXISTS ja4_processing.view_dashboard_variability;
-- Les nouvelles vues (view_dashboard_entities, view_dashboard_user_agents,
-- view_ai_features_24h) sont créées par deploy_views.sql (section finale).
-- Les exécuter ici revient à rejouer cette section de deploy_views.sql.
