22 lines
944 B
Markdown
22 lines
944 B
Markdown
# DD-012 — Rimandare la migrazione degli ID giocatore
|
||||
|
|
|
|||
|
|
**Data:** agosto 2026
|
|||
|
|
**Stato:** Accettata
|
|||
|
|
|
|||
|
|
**Contesto**
|
|||
|
|
L’app usa identificativi semplici (`g1`, `g2`, …) collegati a presenze, voti, palloni e altre funzioni già in uso. Nel database esiste anche una tabella `giocatori` con UUID, non collegata al codice attuale.
|
|||
|
|
|
|||
|
|
**Decisione**
|
|||
|
|
Per ora **non** unificare gli ID. I nuovi dati del profilo si agganciano agli identificativi già in uso. La migrazione verso UUID resta un lavoro separato, pianificato e testato.
|
|||
|
|
|
|||
|
|
**Alternative scartate**
|
|||
|
|
|
|||
|
|
- Migrare subito tutto a UUID → rischio alto di rompere presenze, voti, scout e notifiche.
|
|||
|
|
|
|||
|
|
**Conseguenze**
|
|||
|
|
|
|||
|
|
- Coesistono due modelli anagrafici fino a migration dedicata.
|
|||
|
|
- `DATABASE.md` va tenuto aggiornato su cosa è “attivo” e cosa è “futuro”.
|
|||
|
|
|
|||
|
|
**Riesame**
|
|||
|
|
Quando il modulo Profilo Giocatore è stabile e c’è tempo per una migration con checklist regressioni completa.
|