Domande sulla documentazione relativa alla revocation list

[qippur]

@astagi Dalla documentazione DRL.md:

[https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1] Il Server risponderà a queste request con delle response contenenti le informazioni necessarie ad aggiornare la DRL versione 1 per renderla equivalente alla versione 3:)

Ho due domande:

1. ottengo una risposta con una DIFF non dalla URL [(https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1)] ma dalla URL [https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1] (senza la parte /check) - ho perso qualcosa della documentazione?
2. non ho capito a quale chunk dell'ultima versione porta la DIFF restituita.

Grazie

[rawmain]

Buongiorno @qippur

In attesa che risponda @astagi , provvedo ad anticipare intanto qualche dettaglio esemplificativo.

ottengo una risposta con una DIFF non dalla URL [(https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1)] ma dalla URL [https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1] (senza la parte /check) - ho perso qualcosa della documentazione?

La GET request Check (path /v1/dgc/drl/check e param version) è una chiamata ispettiva = restituisce solo i dati di controllo per le operazioni pre/post-download, non le entry in Snapshot/Diff (che invece ottieni a seguito della get request con path /v1/dgc/drl).

In base a param version=X in request, la relativa response ti fornisce infatti :

• versione corrente Y (version)

• numero di chunk (totalChunk) da scaricare per lo specifico aggiornamento diff entry X->Y (considerando che numero max entry - insertion + deletion - per singolo chunk è 10000)

• numero di entry da aggiungere / rimuovere (numDiAdd / numDiDelete) per la reconciliation DB locale di aggiornamento X->Y

• numero di entry univoche, che devono risultare in DB locale a seguito della reconciliation (totalNumberUCVI)

Se prendiamo in esame p.es. l'ultima versione 36, avremo quindi la seguente tabella di riepilogo per i distinti aggiornamenti attuali diff X->Y, a seconda della situazione X di partenza (dove X=0 corrisponde a DB locale vuoto/resettato).

fromVersion (X)	version (Y)	numDiAdd (insertions)	numdiDelete (deletions)	totalChunk	totalNumberUCVI
0	36	219075	0	22	219075
1	36	219075	0	22	219075
2	36	219075	0	22	219075
[...] fino a 25	36	219075	0	22	219075
26	36	121400	271025	40	219075
27	36	121375	265974	39	219075
28	36	121291	257775	38	219075
29	36	121210	236386	36	219075
30	36	121228	168764	29	219075
31	36	121388	97177	22	219075
32	36	121417	60329	19	219075
33	36	121444	33996	16	219075
34	36	66609	23932	10	219075
35	36	39698	14409	6	219075

Come puoi vedere, a seconda della versione X per cui si effettua il controllo ispettivo, variano insertions/deletions necessarie per allineamento a snapshot versione 36 (219075 entry univoche).

Di conseguenza variano anche contenuto & numero dei chunk da scaricare per singolo specifico aggiornamento X->36, considerando il limite di 10000 max entry complessive (insertions+deletions) per singolo chunk.

2. non ho capito a quale chunk dell'ultima versione porta la DIFF restituita.

In assenza di problemi/anomalie in download e/o lato client, l'aggiornamento diff X->Y (download di m chunk con insertions + deletions) deve allinearti appunto alla situazione DB locale, che avresti tramite l'aggiornamento 0->Y (download di n chunk solo insertions).

Pertanto, una volta scaricato l'ultimo chunk m-esimo, previsto dallo specifico diff X->Y, devi ritrovarti lo stesso numero di entry (totalNumberUCVI) dopo la DB reconciliation.

[qippur]

Quindi se ho capito bene, le risposte alle mie due domande sono:

ottengo una risposta con una DIFF non dalla URL [( https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1)] ma dalla URL [ https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1] (senza la parte /check) - ho perso qualcosa della documentazione?

ciò che ho capito è che la URL che ritorna un json contenente un capo "delta" come questo:

{ "id": "61bcc7c3da0f876422c6a6a8", "fromVersion": 1, "version": 3, "chunk": 1, "lastChunk": 2, "delta": { "insertions": [ "/56vInsThTXNJ9x2GrAXaDaVc7HA0j08FayveKey7KA=", "/sQVKUBUxDmT21FRm6vnPOA5rheTEYOBRIaP22gEXJO=", "63tnu42yVyNCpTjAIq2NsabINN5B19721c10RdYmDjk=", "AOXGyNOJID212fTePArNVFnqW4k23YGjkny405FqwEk=", "Et/XFDeE+v2z/hIL7dec0071e14XeT1YPPdwefavOvA=", "PVezXeW/CuesjOSE9gA4DGmtceOMJHp/VUb7V78tP7c=", "RCTq02Ynu4jGkPEVkjgWrgvINxflivul+sUPSwqMpuo=" ], "deletions": [] }, "sizeSingleChunkInByte": 510, "totalNumberUCVI": 40 }

è https://get.dgc.gov.it/v1/dgc/drl?version=X&chunk= https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1Y e non https://get.dgc.gov.it/v1/dgc/drl/check?version=X&chunk=Y https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1 (la versione corretta è quindi senza la parte /check) come invece riportato nell'ultimo esempio della documentazione https://github.com/ministero-salute/it-dgc-documentation/blob/master/DRL.md. Potrebbe quindi essere necessario correggere la URL dell'ultimo esempio. Corretto?

--

non ho capito a quale chunk dell'ultima versione porta la DIFF restituita.

ciò che hgo capito è che una GET come questa: https://get.dgc.gov.it/v1/dgc/drl?version=11&chunk= https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=12

che ottiene una risposta come questa con il json contenente un campo "delta" (i dati non sono reali)

{ "id": "61bcc7c3da0f876422c6a6a8", "fromVersion": 11, "version": 36, "chunk": 1, "lastChunk": 22, "delta": { "insertions": [ "/56vInsThTXNJ9x2GrAXaDaVc7HA0j08FayveKey7KA=", "/sQVKUBUxDmT21FRm6vnPOA5rheTEYOBRIaP22gEXJO=", "63tnu42yVyNCpTjAIq2NsabINN5B19721c10RdYmDjk=", "AOXGyNOJID212fTePArNVFnqW4k23YGjkny405FqwEk=", "Et/XFDeE+v2z/hIL7dec0071e14XeT1YPPdwefavOvA=", "PVezXeW/CuesjOSE9gA4DGmtceOMJHp/VUb7V78tP7c=", "RCTq02Ynu4jGkPEVkjgWrgvINxflivul+sUPSwqMpuo=" ], "deletions": [] }, "sizeSingleChunkInByte": 510, "totalNumberUCVI": 40 }

serve per portare i miei dati dal chunk 2 della versione 11 al chunk 1 (e non al 22, quindi ad un completo allineamento) della versione 36. Dovrò quindi sempre scaricare per intero i chunk dal 2 all'ultimo indicato dal campo "lastChunk", della versione 36. Corretto?

Un'ultima osservazione: ho notato che se la versione di partenza indicata nella GET è troppo distante da quella corrente, il json di risposta non contiene un campo "delta". Corretto? Qual è il criterio che determina l'invio o meno del campo "delta"?

Grazie per la pazienza.

--

Il giorno mar 11 gen 2022 alle ore 03:02 RAW MAIN @.***> ha scritto:

Buongiorno @qippur https://github.com/qippur

ottengo una risposta con una DIFF non dalla URL [( https://get.dgc.gov.it/v1/dgc/drl/check?version=1&chunk=1)] ma dalla URL [ https://get.dgc.gov.it/v1/dgc/drl?version=1&chunk=1] (senza la parte /check) - ho perso qualcosa della documentazione?

La GET request Check (path /v1/dgc/drl/check e param version) è una chiamata ispettiva = restituisce solo i dati di controllo per le operazioni pre/post-download, non le entry in Snapshot/Diff.

In base a param version=X in request, la relativa response ti fornisce infatti :

-

versione corrente Y (version)

numero di chunk (totalChunk) da scaricare per lo specifico aggiornamento diff entry X->Y (considerando che numero max entry - insertion + deletion - per singolo chunk è 10000)

numero di entry da aggiungere / rimuovere (numDiAdd / numDiDelete) per la reconciliation DB locale di aggiornamento X->Y

numero di entry univoche, che devono risultare in DB locale a seguito della reconciliation (totalNumberUCVI)

Se prendiamo in esame p.es. l'ultima versione 36, avremo quindi la seguente tabella di riepilogo per i distinti aggiornamenti attuali diff X->Y, a seconda della situazione X di partenza (dove X=0 corrisponde a DB locale vuoto/resettato). fromVersion (X) version (Y) numDiAdd (insertions) numdiDelete (deletions) totalChunk totalNumberUCVI 0 36 219075 0 22 219075 1 36 219075 0 22 219075 2 36 219075 0 22 219075 [...] fino a 25 26 36 121400 271025 40 219075 27 36 121375 265974 39 219075 28 36 121291 257775 38 219075 29 36 121210 236386 36 219075 30 36 121228 168764 29 219075 31 36 121388 97177 22 219075 32 36 121417 60329 19 219075 33 36 121444 33996 16 219075 34 36 66609 23932 10 219075 35 36 39698 14409 6 219075

Come puoi vedere, a seconda della versione X per cui si effettua il controllo ispettivo, variano insertions/deletions necessarie per allineamento a snapshot versione 36 (219075 entry univoche).

Di conseguenza variano anche contenuto & numero dei chunk da scaricare per singolo specifico aggiornamento X->36, considerando il limite di 10000 max entry complessive (insertions+deletions) per singolo chunk.

1. non ho capito a quale chunk dell'ultima versione porta la DIFF restituita.

In assenza di problemi/anomalie in download e/o lato client, l'aggiornamento diff X->Y (download di m chunk con insertions + deletions) deve allinearti appunto alla situazione DB locale, che avresti tramite l'aggiornamento 0->Y (download di n chunk solo insertions).

Pertanto, una volta scaricato l'ultimo chunk m-esimo, previsto dallo specifico diff X->Y, devi ritrovarti lo stesso numero di entry ( totalNumberUCVI) dopo la DB reconciliation.

— Reply to this email directly, view it on GitHub https://github.com/ministero-salute/it-dgc-documentation/issues/7#issuecomment-1009531752, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACXMXUIJJYLEBNJJHRMWQYDUVOFU3ANCNFSM5LPO5P6A . Triage notifications on the go with GitHub Mobile for iOS https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675 or Android https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub.

You are receiving this because you were mentioned.Message ID: @.***>

[rawmain]

Buonasera @qippur

Potrebbe quindi essere necessario correggere la URL dell'ultimo esempio. Corretto?

Testo + dettagli dell'esempio sono corretti, ma effettivamente vi erano comunque 2 URL da correggere. Relativo commit di fix (c7f9030) confluito ieri, per cui ora anche gli URL sono ok.

serve per portare i miei dati dal chunk 2 della versione 11 al chunk 1 (e non al 22, quindi ad un completo allineamento) della versione 36. Dovrò quindi sempre scaricare per intero i chunk dal 2 all'ultimo indicato dal campo "lastChunk", della versione 36.

L'allineamento avviene tramite DB reconciliation delle insertion/deletion contenute nei chunk scaricati & è cmq relativo alla versione, NON ai numeri dei chunk.

Pertanto, riprendendo la tabella del mio precedente messaggio, in caso p.es. di aggiornamento dalla versione 26 del DB locale alla 36, vanno scaricati tutti i (40) chunk, che contengono appunto i diff add/delete rispetto alla versione 26.

ho notato che se la versione di partenza indicata nella GET è troppo distante da quella corrente, il json di risposta non contiene un campo "delta".

Come indicato nella documentazione, dipende dalle policy di retention snapshot sulla piattaforma = le vecchie versioni vengono gradualmente rimosse. Infatti per i client, che hanno in DB locale le entry di una versione rimossa, la loro chiamata ispettiva comporta azzeramento DB locale & download di chunk version-snapshot solo insertions.

Se guardi sempre quella tabella, vedrai che - oltre ovviamente alle chiamate in condizioni iniziali con DRL vuota (fromVersion 0) - anche le chiamate per aggiornamento dalle versioni 1,2,..., 25 comportano download snapshot (non diff) versione 36 dei medesimi 22 chunk contenenti solo insertions.

Ciò avviene perché appunto le versioni dalla 1 alla 25 sono state rimosse, per cui non vi è più generazione/restituzione dei relativi diff chunk rispetto alla versione 36.