Siden bruges til dokumentation af beslutninger vedrørende konvertering af Joblog-data fra Classic DFDG til Jobsearch.
ID | Spørgsmål | Beslutning | Dato |
|---|---|---|---|
1 | Konverteringen gennemføres til SIT-testmiljøerne i 2024-3? Jobsearch flyttes til SIT i 2024-4. | Søby: Indikativt, konvertering gennemføres på Kyndryl og så taxa i prod (backup/restore). TEMA! Løftes med STAR | 2024-06-21 |
2 | Mapningsdokument kurant? Opdateres hvornår? | Modtaget 2024-06-20 i version 3. | |
3 | Historik? Der er en kolonne i CoreEntryHistory, ChangeTypeId, der ikke medtages til det nye domæne. LSS’en viser den seneste version (også når der alene er data i historik-tabellen) af en log med historik, dog ikke rækker med ChangeTypeId=3, slettet. Se eksempel nedenfor. I den konverterede fact-tabel er der ingen CUD-kolonne, så hvordan ved man om Jobloggen er slettet (slettemarkeret) af borgeren/andre? Samme observation i alle sattelitterne. 3’ere optræder kun i Document og CoreEntry | DeletedDateTIme i metadata, rækken skal i history… | 2024-06-21 |
4 | Dokumenter? Hvad med de fysiske dokumenter i DocumentRepository?Taxamodel. Se også spm 1. | Vi mangler Document.Document table. Det kommer når vi begynder at implementere dokument service metoder | 2024-06-21 |
5 | Index-tabeller - skal de konverteres (ikke temporale)? Tabellerne får data fra batchjobbet DFDG-JL-JoblogFullIndexBuilder | Ikke med i konverteringsarket 2024-06-14 Beslutning: skal ikke konverteres | 21/6-2024 |
6 | UnemploymentFundBranchCode opdateres i ExternalData.UnemployementFund | BI opdaterer tabellen. | 2024-06-21 |
7 | MetadataJSON i version 1? Vi plejer at konvertere i Version 0. | Vi sætter version 0 | 21/6-2024 |
8 | OptionalColumnsRemoved? Data om GDPR-sletninger? Som jeg forstår det er slettereglen 6 år, men som eksemplet nedenfor viser, så indeholder History-tabellen ældre rækker (med slettet indhold), der vises i LSS’en. | Næppe relevant. | 2024-06-21 |
9 | Som datamodellen er implementeret kan fact-tabellen kun holde den seneste version af en joblog med identifier som PK. Er dette korrekt? LSS’en viser versioner af Joblogs. | Seneste version i fact, resten i historik | 2024-06-21 |
10 | Tekstlængde, comment, reduktion? “Måske”? | ? | 2024-06-21 |
11 | t15, ikke t11. | 2024-06-21 | |
12 | I må meget gerne tage stilling til hvad der skal gøres med konvertering afmetadata for dokumenter, der er slettet i DocumentRepository, men hvor der evt stadig er referencer i metadata. Daniel har været med til rehab, måske skal det være på samme måde? | ||
13 | RowValidFrom og RowValidFrom konstrueres. Se nedenfor. | ||
14 | Dokumenter markeret som slettede af brugeren i DocumentHistory med StatusTypeIdentifier=2 får slettet referencen til CoreEntry. Logikken er at dokumentets metadata skrives til History med type=1 og derefter oprettes en række i History med Type=2 og ellers ingen metadata på rækken. | I lyset af findings omkring brugen af type 2 og 3 i StatusTypeIdentifier betyder det at History løbes igennem for sletninger og arver metadata fra rækken med type=1, hvis den findes i History ved konvertering. Da rækken er slettet fra fact-tabellen mister vi CreatedDate, da både type 1 og type 2 får slettet datoerne fra fact-tabellen, når de skrives til History. 2 og 3 konverteres ikke fra Fact-tabellen. 1 konverteres fra Fact. Få nye registreringer er uden fysiske dokumenter, men det skyldes nok et batchjob, der sletter på dato. Konverteres. 1 og 2 konverteres fra History. 2 kun hvis der findes en korresponderende 1’er, ellers kan rækken ikke knyttes til en borger. | |
15 | Document.DeletedDate er senest anvendt i 2019 med FileIdentifier “00000000-0000-0000-0000-000000000000” og er <> NULL på 103 rækker. Seneste opdatering med valid FileIdentifier er fra 2016. Kolonnen konverteres, men bruges den? | ||
16 | StatusTypeIdentifier. Kun værdien 1, der benyttes i fact siden 2020. 1, 2 i History. 3 kun i fact, men ikke siden 2020 | Se ID 14 og ID17 for værdien 3. | |
17 | Documents fact-tabellen indeholder 19 mio. rækker, hvor det fysiske dokument alle er slettet. Gamle slettemarkerede rækker fra før 1/7 2020 med type=3, | Hvis konvertering - flyttes til historik? |
Spørgsmål 3
Nedenstående borger har alene Joblog-rækker i CoreEntryHistory.
15334353 bærer oplysningen om sletningen, der vises på den oprindelige version, 15334120.
Spørgsmål 13
Der er flere problemstillinger for RowValidFrom og RowValidTo med udgangspunkt i de originale datakilder.
CreatedDate er ikke fastholdt i historiske versioner, men fastholdes på fact-rækken.
Når rækker blev opdateret, så opdaterede man Fact-rækken først og skrev derefter rækken til History, men med Timestamps. Det vil sige at UpdatedDate er ældre på rækken i fact-tabellen end på den række, der blev skrevet til historik-tabellen. From og To bygges som følger:
UpdatedDate vælges som RowValidFrom på Fact-rækken og RowValidTo på den seneste række i History. Dermed overskriver vi UpdatedDate på den seneste række i History.
Dette sætter sig ned igennem versionerne til den ældste, der får sat RowValidFrom som CreatedDate
Se nedenfor:
Created | Updated | ChangeId | RowValidFrom | RowValidTo |
2019-03-10 08:34:25.4133333 | 2019-04-01 08:16:18.3066667 | Fact | 2019-04-01 08:16:18.3066667 | 9999-12-31 23:59:59.9999999 |
2019-03-10 08:34:25.4133333 | 2019-04-01 08:16:18.3364495 | Opdateret History | 2019-03-11 10:07:14.8598133 | 2019-04-01 08:16:18.3066667 |
2019-03-10 08:34:25.4133333 | 2019-03-11 10:07:14.8598133 | Opdateret History | 2019-03-10 08:34:25.8190942 | 2019-03-11 10:07:14.8598133 |
2019-03-10 08:34:25.4133333 | 2019-03-10 08:34:25.8190942 | Oprettet History | 2019-03-10 08:34:25.4133333 | 2019-03-10 08:34:25.8190942 |
For slettede rækker uden rækker i Fact-tabellen slette-markeres rækken i MetadataJSON og rækkerne i History-tabellen dateres som følger.
Created | Updated | RowFrom | RowTo | |||
NULL | 2022-12-30 11:07:24.0340325 | Slettet History | 2022-12-30 11:07:24.0340325 | 2022-12-30 11:07:24.0340325 | ||
NULL | 2022-12-05 13:27:25.7194658 | Oprettet History | 2022-12-05 13:27:25.7194658 | 2022-12-30 11:07:24.0340325 |