...

SELECT t1.ValidFrom, t1.FromDate, t1.ToDate, t1.SorId, t1.ParentSorId, t1.HealthInstitutionSorId,
       t1.ProviderId, t1.ShakId, t1.EntityName, t1.InstitutionOwnerSorId,
       t1.InstitutionOwnerCvrNumberId, t1.EntityTypeId, t1.EntityTypeName
FROM SOR2SorEntity t1
JOIN (
        SELECT UniqueCurrentKey, MAX(ValidFrom) as MaxValidFrom
        FROM SOR2SorEntity
        WHERE FromDate >= :date_cutoff
        OR (FromDate = 
                (
 	                SELECT MAX(FromDate)
                	FROM SOR2SorEntity t3
                	WHERE t3.SorId = SOR2SorEntity.SorId
                    AND FromDate <= :date_cutoff
                ) 
                AND (ToDate is NULL OR ToDate > :date_cutoff)
        )
        GROUP BY UniqueCurrentKey
) t2 ON t1.UniqueCurrentKey = t2.UniqueCurrentKey AND t1.ValidFrom = t2.MaxValidFrom
;

Parameteren ":date_cutoff" (linje 8) udfyldes med property "sores.retention.period" som beskrevet i driftsvejledningen. 

...

Der skal vælges de rækker, hvor der for hver gruppering på nøglen UniqueCurrentKey, kun vælge dén række, der har den nyeste ValidFrom (date).

UniqueCurrentKey er en sammensat nøgle, som består af <SorId, FromDate>. Dette er ikke en unik nøgle, da der kan forekomme adskillige rækker af disse. Men ovenstående join vælges kun dén af de rækker, som har nyeste ValidFrom.

FromDate er den forretningsmæssige startdato for hvornår er række er gyldig. Denne kan adskille sig fra indlæsningstidpunktet (hvornår SOR2-importeren har indlæst pågældende data), og ValidFrom benævnes derfor den tekniske fra-dato, som er sat af importeren. Er der flere rækker med samme SorId og FromDate, bruges derfor ValidFrom til at vælge den række, der aktuelt er gyldig på den FromDate for den SorId.

Bemærk, at der i JOIN-betingelsen også forekommer en  "OR (FromDate =" (linje 9). Dette skyldes, at vi ud over historikken for det angivne dato-interval, også har behov for at sikre os, at seneste gyldige SorEntity - uanset FromDate - også altid er med i indlæsningen. Som eksempel kunne man forestille sig en SorEntity, hvor seneste FromDate lå tre år tilbage, og derfor vil den ikke ligge inden for "FromDate > :date_cutoff", hvis ":date_cutoff" kun var to år tilbage.

Til den inderste query tilføjes "AND (ToDate is NULL OR ToDate > :date_cutoff)", da en SorEntity med start udenfor intervallet kun har relevans, hvis den stadig er aktiv inden for intervallet. 

ReplacedSORMap

For SOR2SorEntity bliver der også læst ind, en liste af sorIds som SOR2SorEntity'ens sorId er blevet erstatte med som bruges til operation ReplacedSORMap.

// Finder hele træet af SorId'er, som er blevet erstattet af en given SorId
// Eksempel: Hvis SorId er 101 og vi har denne data struktur:
//   101
//    ├── 102
//    ├── 103
//    │   └── 104
//    └── 105
//        └── 106
// Vil den returner alle disse [102, 103, 104, 105, 106] SorId'er.
public List<Long> getSorReplacedByEntities(Long sorId) {
    Set<Long> visitedSorIds = new HashSet<>();
    List<Long> result = new ArrayList<>();
    recursiveFetch(sorId, visitedSorIds, result);
    return result;
}

private void recursiveFetch(Long sorId, Set<Long> visitedSorIds, List<Long> result) {
    // Hvis vi allerede har fundet SorId'et, så returner for at undgå uendelig rekursion
    // Data'en er ikke cirkulær, så dette burde ikke ske
    if (visitedSorIds.contains(sorId)) {
        return;
    }
    visitedSorIds.add(sorId);

    // Find alle SorId'er som er blevet erstattet af den givne SorId
    String query = "SELECT ReplacedBySorId FROM SOR2SorReplacedByEntities WHERE ReplacedSorId = :sorId";
    HashMap<String, Object> parameters = new HashMap<>();
    parameters.put("sorId", sorId);
    List<Long> replacedByIds = jdbcTemplate.queryForList(query, parameters, Long.class);
    
	// Tilføj de fundet sorId'er til resultatet
    result.addAll(replacedByIds);
    
	// Recursivt kald for hver af de fundne underliggende sorId'er for at finde alle SorId'er i træet
    for (Long id : replacedByIds) {
        recursiveFetch(id, visitedSorIds, result);
    }
}

UniqueCurrentKey er en sammensat nøgle, som består af <SorId, FromDate>. Dette er ikke en unik nøgle, da der kan forekomme adskillige rækker af disse. Men ovenstående join vælges kun dén af de rækker, som har nyeste ValidFrom.

FromDate er den forretningsmæssige startdato for hvornår er række er gyldig. Denne kan adskille sig fra indlæsningstidpunktet (hvornår SOR2-importeren har indlæst pågældende data), og ValidFrom benævnes derfor den tekniske fra-dato, som er sat af importeren. Er der flere rækker med samme SorId og FromDate, bruges derfor ValidFrom til at vælge den række, der aktuelt er gyldig på den FromDate for den SorId.

Bemærk, at der i JOIN-betingelsen også forekommer en  "OR (FromDate =" (linje 9). Dette skyldes, at vi ud over historikken for det angivne dato-interval, også har behov for at sikre os, at seneste gyldige SorEntity - uanset FromDate - også altid er med i indlæsningen. Som eksempel kunne man forestille sig en SorEntity, hvor seneste FromDate lå tre år tilbage, og derfor vil den ikke ligge inden for "FromDate >= :date_cutoff", hvis ":date_cutoff" kun var to år tilbage.

...