source: Klonkt/src/services/ActivityPubService.js@ d14bf1c

De merksteen wordt een koppeltabel in plaats van een afleiding (shaer-n05)

Barts onderbuik, en hij had gelijk. De merksteen leunde op MAX(rowid) over vier
tabellen: een TOEVALLIGE eigenschap, geen feit dat ergens is opgeschreven.
Dezelfde fout als reacties uitlezen uit ap_timeline.liked, en met dezelfde soort
gebreken -- hij zag aangroei maar geen verandering, en hij kon achteruit lopen.

Nu ap_feed_state: een rij per bericht per tijdlijn, met een oplopende rev en een
kind (new | updated | deleted). Dat beantwoordt drie vragen die anders drie eigen
oplossingen zouden krijgen: is er iets veranderd sinds N, WAT is er veranderd, en
is dit bericht bewerkt. Die derde maakt de "bewerkt"-markering uit shaer-of7
straks een leesactie in plaats van een bouwsel.

Een STAND en geen logboek: vijf keer bewerken blijft één rij, dus er groeit niets
en er valt niets te snoeien. Mijn eerste test ging uit van een log en viel daar
terecht over.

Bijgehouden door TRIGGERS, om dezelfde reden dat er geen emitter is: een trigger
zit in de database, dus geen codepad kan hem vergeten. De teller staat in een
eigen tabel en niet in MAX(rev), want die zou terugzakken zodra de hoogste rij
verdwijnt -- en dan denkt een client dat er niets gebeurd is.

DE VAL WAAR DIT BIJNA IN LIEP: een like schrijft ap_timeline.liked en een 🔁
schrijft .boosted. Zonder afbakening zou je eigen like het bericht als BEWERKT
merken en elke wachtende client wekken. Vandaar de UPDATE OF-kolomlijsten; die
zijn niet decoratief.

Nagemeten wat ik wilde zien voordat dit erin ging: een INSERT OR IGNORE die niets
doet vuurt geen trigger, en de trigger op ap_interactions joint correct via posts
naar sites (die tabel draagt zelf geen slug).

De cursor is nu een getal in plaats van "23.2.8.2". Een client met een oude
cursor krijgt meteen antwoord met de nieuwe; dat heelt zichzelf.

16 tests in feed-wait. Suite 544/544.