SKLTP TAK - Beskrivning av implementation för borttagning

Implementationen för borttagning av element har över tiden blivit allt mer komplex. Den senaste genomgången av implementationen kom fram till att den fungerar enligt beskrivningen nedan.

Varianter på borttagning:

• ”Vanlig” borttagning (t.ex. Administrera vägval => Visa => Ta bort)

  • Alt 1 – Posten har inte publicerats (fältet pubversion är null): posten tas bort helt från databasen.

  • Alt 2 – Posten har publicerats: posten tas inte bort från databasen utan det görs en ”soft delete” genom att markera den som raderad (fälted deleted)

• Borttagning via JSON beställning

  • Alt 1 – postens fromtidpunkt är efter (eller lika med) genomförandetidpunkt i JSON: posten markeras som raderad via soft delete (oavsett pubversion)

  • Alt 2 – postens fromtidpunkt är före genomförandetidpunkt i JSON: posten markeras INTE som raderad utan tomtidpunkt sätts till en dag före genomförandetidpunkt i JSON. D.v.s. det är egentligen ingen radering utan snarare att man sätter ett utgångsdatum.

Soft-delete-funktionaliteten är dessvärre inte en optimal implementation. Den är tillagd en gång i tiden för att ha kvar raderade poster i databasen och skilja på aktiva och raderade via fältet deleted. I samband med det är det tillagt constraints som dessa:

ALTER TABLE `Tjanstekontrakt` ADD CONSTRAINT `UC_NAMNRYMD` UNIQUE (`namnrymd`,`deleted`);

ALTER TABLE `Vagval` ADD CONSTRAINT `UC_VAGVAL_ADRESS` UNIQUE (`anropsAdress_id`,`tjanstekontrakt_id`,`logiskAdress_id`,`fromTidpunkt`,`tomTidpunkt`,`deleted`);

Troligtvis har man kommit på att man vill kunna ha fler än en raderad post av ”samma” post. Men det går inte p.g.a. exempelvis namnrymden ovan, man kan bara ha två poster med samma namnrymd, en med deleted = true och en med deleted = false. För att lösa det har man infört att deleted kan vara null för att markera att posten är raderad. (Eftersom null i databassammanhang inte räknas som samma som ett annat nullvärde så kan man då ha flera raderade poster.) Det fungerar så länge man ser till att bara använda deleted = false och deleted = null. Om någon däremot skulle få för sig att manuellt sätta deleted = true i databasen i tron att posten då är markerad som raderad kan det bli problem:

• Nu kontrollerar koden deletedstatus enbart genom att jämföra med null. Deleted = true i databasen hanteras alltså som deleted = false

• Om man har två identiska rader förutom att en har deleted = true och en deleted = false så har man i praktiken fått en otillåten dubblett.

Det vore därför lämpligt att uppdatera implementeringen så att deleted = true hanteras på samma sätt som deleted = null + ett varningsmeddelande i loggen om man stöter på poster med deleted = true.