Implementationen för borttagning av element är inte helt uppenbar. I nuläget verkar det se ut har över tiden blivit allt mer komplex. Den senaste genomgången av implementationen kom fram till att den fungerar enligt beskrivningen nedan.
...
Soft-delete-funktionaliteten är lite av ett fulhack.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 `Vagval` ADD CONSTRAINT `UC_VAGVAL_ADRESS` UNIQUE (`anropsAdress_id`,`tjanstekontrakt_id`,`logiskAdress_id`,`fromTidpunkt`,`tomTidpunkt`,`deleted`);
Sedan kommer det roliga, tydligen Troligtvis har man kommit på att man vill kunna ha fler än en raderad post av ”samma” post. Men det går inte för t.ex. namnrymd p.g.a. exempelvis namnrymden ovan, man kan bara ha två poster med samma namnrymd, en med deleted = true och en med deleted = false. Så då 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 ju så länge man ser till att bara använda deleted = false och deleted = null. Men om 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 lite skumtproblem:
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 borde vi åtminstone uppdatera vore därför lämpligt att uppdatera implementeringen så att vi hanterar deleted = true hanteras på samma sätt som deleted = null + ett varningsmeddelande i loggen om man stöter på poster med deleted = true.