Een concreet voorbeeld van het risico om iets zelf te ontwikkelen

In mijn vorige blog beschreef ik over de strategie die ik heb om metadata aan de relaties tussen posts (en ook users) toe te voegen. Daar ben ik direct mee aan de slag gegaan. Een eerste concept heb ik binnen enkele minuten gemaakt omdat ik de een simpele en doeltreffende methode gebruik die perfect aansluit hoe WordPress zelf in elkaar zit.

Het toevoegen en ophalen van de metadata aan de relaties mag dan heel eenvoudig zijn. De uitdaging is in dit geval de integriteit van de database. Wanneer een bepaalde relatie tussen twee posts wordt verwijderd dan blijft de metadata die daaraan gekoppeld is nog gewoon in de database staan. Daarmee raakt de database vervuild.

Die vervuiling is op zichzelf geen al te groot probleem. Ook kan niet worden gezegd dat daardoor de database direct corrupt raakt of anderzijds de integriteit van de database in het geding is. Dat gebeurt wel op het moment dat de relatie opnieuw wordt toegevoegd én de metadata die een oude relatie beschrijft als metadata van de nieuwe relatie worden beschouwd.

Dat probleem ontstaat in het geval van de ORM die ik in Wpx gebruik omdat de relatie tussen twee posts géén (eigen) uniek ID heeft. De koppeling vindt daardoor plaats met de foreign_key van de post waaraan gekoppeld wordt. Die zal bij een oude en nieuwe relatie daarom hetzelfde zijn.

Het is daarom belangrijk om er rekening mee te houden dat dit kan gebeuren. Daarvoor zijn er verschillende mogelijkheden. De meest accurate zijn om bij het toevoegen en/of verwijderen van een bepaalde relatie de (oude) metadata te verwijderen en vervolgens eventuele nieuwe metadata toe te voegen. Daarnaast is het ook mogelijk om dit te doen met een cronjob die speurt naar metadata die niet meer aan een relatie is gekoppeld en deze verwijderd.

De mogelijkheid om met een timestamp of een checksum als extra metadata te controleren of de relatie nog wel de juiste is zie ik niet. Het probleem is dat hiermee niet kan worden gecontroleerd of dat de relatie op enig moment verwijderd is en later weer is toegevoegd. Ook het ID in de metadata tabel zelf is hier niet voor geschikt omdat bij wijzigingen van posts vaak eerst (alle) metadata die wordt bijgewerkt wordt verwijderd en vervolgens weer wordt toegevoegd.

Dit laatste maakt ook de eerste twee oplossingen een uitdaging om te implementeren. Het verwijderen en weer toevoegen van de metadata zijn twee verschillende processen. Er wordt dus een losse verwijdering waargenomen (die te filteren is met een hook) en vervolgens een losse toevoeging waargenomen (die eveneens te filteren is met een hook).

Ook deze twee processen in de gaten houden is een uitdaging. Het probleem is namelijk dat een verwijdering niet perse gevolgd hoeft te worden door het (onmiddellijk) weer toe te voegen. Het probleem is dat het systeem met filters niet weet of die toevoeging nog zal volgen. Wanneer dat niet het geval is, dan moet de metadata worden verwijderd alleen twijfel ik er over of daar nog (volledige) zekerheid over te krijgen is. Dat soort onzekerheid mag er simpelweg niet zijn.

Het probleem geldt ook met het filteren op het toevoegen van een relatie. De toevoeging van de relatie kan vooraf zijn gegaan door een verwijdering van die relatie. Die verwijdering moet dan wel met zekerheid zijn geregistreerd door het systeem. Ook hier moet daar absolute zekerheid over zijn. Het probleem is dat die absolute zekerheid er niet is.

Dit is dus precies het risico dat ik in een eerdere blog beschreef over dingen zelf bouwen. De dingen die er al zijn hebben hun beperkingen alleen zijn ze wel volledig doorontwikkeld en heb je daarmee als programmeur ook véél meer zekerheid dat de applicatie die je maakt ook zal functioneren zoals dat bedoeld is.