...

Cachen indlæses ved kald til "/reload" som beskrevet i driftsvejledningen. Følgende query danner grundlag for at fylde cachen med entiteter fra tabellen SOR2SorEntity. En tilsvarende query er lavet til at indlæse fra SOR2SorShakMap.

SOR2SorEntity:

WITH filtered AS (
  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 (
         *
  FROM SOR2SorEntity
  WHERE FromDate > :date_cutoff
  UNION ALL
  SELECT t.*
  FROM SOR2SorEntity t
  JOIN (
    SELECT SorId, MAX(FromDate) AS FromDate
    FROM SOR2SorEntity
    WHERE FromDate <= :date_cutoff
    GROUP BY SorId
  ) m
    ON m.SorId = t.SorId
   AND m.FromDate = t.FromDate
  WHERE t.ToDate IS NULL OR t.ToDate > :date_cutoff
)
SELECT f1.*
FROM filtered f1
JOIN (
  SELECT UniqueCurrentKey, MAX(ValidFrom) asAS MaxValidFrom
        FROM SOR2SorEntity
        WHERE FromDate >= :date_cutoff
        OR (FromDate = 
                (
 	                SELECT MAX(FromDate)
                	FROM SOR2SorEntity t3
                	WHERE t3.SorId = SOR2SorEntity.SorId
                ) 
                AND (ToDate is NULL OR   FROM filtered
  GROUP BY UniqueCurrentKey
) pick
  ON pick.UniqueCurrentKey = f1.UniqueCurrentKey
 AND pick.MaxValidFrom    = f1.ValidFrom;

SOR2SorShakMap:

SELECT
  t1.ValidFrom,
  t1.FromDate,
  t1.ToDate,
  t1.SorId,
  t1.SorHealthInstitutionSorId,
  t1.ShakId
FROM SOR2SorShakMap t1
JOIN (
  SELECT t2.UniqueCurrentKey, MAX(t2.ValidFrom) AS MaxValidFrom
  FROM SOR2SorShakMap t2
  LEFT JOIN (
    SELECT SorId, MAX(FromDate) AS LatestFromDate
    FROM SOR2SorShakMap
    WHERE FromDate <= :date_cutoff
    GROUP BY SorId
  ) latest ON t2.SorId = latest.SorId
  WHERE t2.FromDate > :date_cutoff
     OR (t2.FromDate = latest.LatestFromDate AND (t2.ToDate IS NULL OR t2.ToDate > :date_cutoff)
        )
        GROUP BY t2.UniqueCurrentKey
) t2t4
  ON t1.UniqueCurrentKey = t2t4.UniqueCurrentKey
 AND t1.ValidFrom = t2t4.MaxValidFrom
;

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

Indlæsning foregår som et join på SOR2SorEntity fra sig selv. En central del af denne join er følgende:

...

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. Glemmer vi denne, risikerer vi derfor at have et "hul" i starten af den periode, som har cut-off date som start.

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

Henter alle erstatningsrelationer mellem SOR-ID’er fra databasen som en flad liste af parent-child forbindelser med gyldighedsperioder. Listen den laver bliver brugt til at lave relationstræet til hurtig opslag i SoresCache.

public List<SorReplacedByDTO> getSorReplacedByMap() {
        String query =
                "SELECT ReplacedSorId, ReplacedBySorId, FromDate, ToDate " +
                "FROM SOR2SorReplacedByEntities";
        List<SorReplacedByDTO> sorReplacedByEntities = jdbcTemplate.query(query, (rs, rowNum) ->
            new SorReplacedByDTO(
                rs.getLong("ReplacedSorId"),
                rs.getLong("ReplacedBySorId"),
                rs.getDate("FromDate").toLocalDate(),
                rs.getDate("ToDate") != null ? rs.getDate("ToDate").toLocalDate() : null
            )
        );

        return sorReplacedByEntities;
    }