A proposito dell'ultimo changelog: rilasciare un file di mapping delle tantissime variazioni

[aborruso]

Buongiorno,
avete annunciato delle importanti modifiche sui nomi dei campi di tante tabelle.

Decine e decine di applicazioni sfruttano queste basi dati, queste modifiche hanno un grosso impatto.

Per una modifica così importante e ricca dovreste pubblicare anche un file machine readable che mappi le modifiche da fare in bulk, e non soltanto un elenco puntato.

Qualcosa come

{
  "file": "consegne-vaccini-latest",
  "campi": [
    {
      "old-name": "fornitore",
      "new-name": "forn"
    },
    {
      "old-name": "codice_NUTS1",
      "new-name": "N1"
    }
  ]
}

Ma anche un semplice CSV, con una struttura come quella di sotto

file	old-name	new-name
consegne-vaccini-latest	fornitore	forn
consegne-vaccini-latest	codice_NUTS1	N1

Sono sicuro che concorderete sulla necessità di questa integrazione.

Grazie

[m-melis]

Incredibile.

Comunque, purtroppo, visti i precedenti dubito ci saranno integrazioni/miglioramenti della modifica annunciata. Felice di essere smentito.

[floatingpurr]

Quella di @aborruso mi pare un'ottima idea per mitigare l'impatto (pesantissimo) delle modifiche sulla nomenclatura dei descrittori dei dati. Perlomeno, le applicazioni che consumano queste informazioni potrebbero utilizzare i file di mapping per rinominare i dati secondo il vecchio formato, garantendo la retrocompatibilità.

In alternativa, ci potrebbe anche stare un repo parallelo community-driven che prende i dati da questo e li riformatta nel vecchio stile. ← e invece no, perché ci cacceremmo in un ginepraio. Info qui sotto.

Edit:

Perché accade tutto questo?

Penso di aver capito la ragione di questa modifica devastante.

tl;dr:

Credo ci si stia imbattendo nei limiti dimensionali dei file, imposti da GitHub. I dump in json sono piuttosto verbosi. Per esempio, il file json di riepilogo sta quasi arrivando a 100M. GitHub dà un warning sui push dei file da 50M+ e non consente i push che superano i 100M, se non con il Git Large File Storage.

Dettagli

Guardiamo la dimensione dei file che contengono i dati:

864B May  5 10:31 .
320B May  5 10:31 ..
977B May  5 10:31 anagrafica-vaccini-summary-latest.csv
6.0K May  5 10:31 anagrafica-vaccini-summary-latest.json
390K May  5 10:31 consegne-vaccini-latest.csv
2.4M May  5 10:31 consegne-vaccini-latest.json
 66B May  5 10:31 last-update-dataset.json
445B May  5 10:31 platea-booster-immunocompromessi.csv
3.5K May  5 10:31 platea-booster-immunocompromessi.json
4.4K May  5 10:31 platea-dose-addizionale-booster.csv
 32K May  5 10:31 platea-dose-addizionale-booster.json
1.8K May  5 10:31 platea-second-booster.csv
 13K May  5 10:31 platea-second-booster.json
4.9K May  5 10:31 platea.csv
 35K May  5 10:31 platea.json
 22K May  5 10:31 punti-somministrazione-latest.csv
102K May  5 10:31 punti-somministrazione-latest.json
147K May  5 10:31 punti-somministrazione-tipologia.csv
742K May  5 10:31 punti-somministrazione-tipologia.json
5.6K May  5 10:31 soggetti-guariti.csv
 42K May  5 10:31 soggetti-guariti.json
 16M May  5 10:31 somministrazioni-vaccini-latest.csv
 83M May  5 10:31 somministrazioni-vaccini-latest.json
734K May  5 10:31 somministrazioni-vaccini-summary-latest.csv
5.7M May  5 10:31 somministrazioni-vaccini-summary-latest.json
1.4K May  5 10:31 vaccini-summary-latest.csv
9.6K May  5 10:31 vaccini-summary-latest.json

Il file somministrazioni-vaccini-latest.json sta raggiungendo dimensioni mastodontiche, rischiando di compromettere il push su GitHub. Per quanto si possa usare il supporto per i file di grandi dimensioni (LFS), GitHub non è un sistema concepito per la gestione di massicci dump dei dati e impone delle limitazioni in merito alle dimensioni dei file, eventualmente aggirabili a pagamento. A tendere, potremmo vedere qualcosa di analogo anche a causa dei json nel repo https://github.com/pcm-dpc/COVID-19.

Mi pare che la strategia di base sia quella di diminuire il peso della descrizione dei campi (che nei json sono ripetuti in modalità chiave:valore), così da ridurre la dimensione totale del file (~ di un fattore 2) e non incappare nel limite dimensionale. Almeno per il momento, perché i dati crescono e i campi, a quanto pare, pure.

A supporto del fatto che il problema sia generato principalmente dal file somministrazioni-vaccini-latest.json c'è proprio il changelog:

Tutto ruota attorno a somministrazioni-vaccini-latest.json e, naturalmente, ai file che referenziano i campi presenti in quel file.

Just guessing. Ma mi pare plausibile.

[aborruso]

Ottima nota @floatingpurr

Speriamo che la mia nota venga accolta

[floatingpurr]

Sì @aborruso! A maggior ragione, visto che la modifica pare inevitabile, un mapping strutturato sarebbe il minimo per mitigare l'impatto di tutto ciò.

[alusiani]

A me sembra che JSON non sia un formato adatto per gestire grandi quantita' di dati, specialmente se viene usata una struttura non ottimizzata in cui identificatori identici vengono ripetuti per ogni microdato. Anche l'idea di avere un grande file cui si fanno delle modifiche usando il sistema di revisione di github mi sembra una cattiva idea in presenza di quandi quantita' di dati. In queste condizioni sarebbe utile pensare a organizzare i dati in file separati di dimensioni medie e non grandi, e possibilmente con formati interni non eccessivamente ridondanti.

[aborruso]

Creato file di mappatura #236