Aan een beroep op de WordPress Core API’s ontkom je soms niet

Bij het bouwen van cascade delete in WordPress merkte ik dat de performance bij het deleten van een bepaalde post door de cascade delete van de daaraan gekoppelde posts niet gunstig was. De veroorzaker was de joint fields generation functie die voor elke post werd aangeroepen bij het opslaan van de “cascade” post status.

Het bovenstaande is gewoon positief. Het generen van joint fields is gewoon een feature van het Wpx framework die perfect werkt én ook specifiek is ingesteld voor het type posts. Mijn eerste gedachte was, nou dan zorg ik er toch voor dat ik het genereren daarvan in bepaalde gevallen uit kan zetten. Probleem opgelost. Daar is geen speld tussen te krijgen.

Het punt is alleen dat het ORM bedoeld is om programmeren op applicatie niveau makkelijker te maken. In dit geval gaat het om het Wpx framework zelf waar iets wordt uitgevoerd. Het framework moet applicatie ontwikkeling niet alleen makkelijker maken. Het moet ook zo stabiel en snel mogelijk zijn. De ORM voegt verschillende zaken toe alleen die zorgen ook voor een verminderde performance.

Daarom heb ik er bij de cascade delete voor gekozen om een rechtstreeks beroep te doen op de WordPress Core API’s om de post status in te stellen. Daarvoor gebruik ik “wp_update_post”. Daarnaast voeg ik – net als WordPress zelf bij het trashen van een post – extra metadata aan een post toe met de post_id van de post die verantwoordelijk is voor de cascade én de oude post status. Daarvoor gebruik ik “update_post_meta”. Op die manier is ook een cascade undelete mogelijk.

In dit geval is performance héél belangrijk. Wanneer je verschillende onderling relaties tussen posts heb dan kan het gebeuren dat er door één post te verwijderen plotseling tientallen of zelfs honderden posts moeten worden verwijderd en daarvan ook weer de metadata, categorieën, tags, etc. Als de ORM voor elk van die acties een paar milliseconden toevoegt dan worden dat al snel hele seconden die de gebruiker moet wachten.

Zeker wanneer het om écht veel data gaat die aan elkaar gekoppeld is en in één actie moet worden verwijderd kan het daarom zelfs noodzakelijk zijn om zelfs buiten de WordPress Core API’s bewerkingen rechtstreeks in de database uit te voeren. Op die manier zou je alle ID’s van posts die moeten worden verwijderd kunnen bepalen en dan met één query per tabel alle data verwijderen.

Dat geeft een gigantische performance verbetering. Daar staat tegenover dat de logica en functies in WordPress zelf én in de ORM ook worden omzeilt. Je zult dus héél erg moeten oppassen dat je de database niet sloopt. Performance is belangrijk. De integriteit van de applicatie is heilig. Pas als je de database integriteit onder alle omstandigheden kan garanderen is rechtstreeks schrijf bewerkingen in de database uitvoeren acceptabel.

Daarbij merk ik ook nog op dat óók het rechtstreeks lezen van gegevens uit de database kan leiden tot het slopen van de database. Wanneer de gegevens die worden opgehaald niet kloppen weer worden weggeschreven dan raakt de database ook corrupt. Wel is de kans daarop aanzienlijk kleiner. Al moet ook dat risico niet worden onderschat.