Provera koja je uvek tačna

U ovom servisu ima 23 UPDATE iskaza. Tačno jedan od njih proverava da li je išta promenio. Ta provera je:

'success' => $n->rowCount() >= 0

rowCount() vraća 0 kada nijedan red nije odgovarao. Nula je veća ili jednaka nuli. Provera prolazi šta god da se desi.

Čemu služi naredba

Čuva jedno polje za potvrdu: da li vlasnik brojača želi nedeljni sažetak mejlom. Adresa živi u zasebnoj tabeli, a red se u njoj pojavljuje tek pošto neko klikne na link za potvrdu u poruci koju je sam zatražio. Četiri brojača imaju takav red. Aktivnih je 2.218.

Dakle, za 99,8% brojača UPDATE ne poklapa nijedan red. Endpoint odgovara success: true a podešavanje se ne čuva, jer nema gde da se sačuva.

Komentar iznad je tačan

Tri linije više, u istoj funkciji:

„Samo tamo gde postoji potvrđen put nazad. Bez njega nema adrese na koju bi pismo moglo da ode — a polje za potvrdu bi obećalo nešto što se ne dešava.“

To je tačno onako kako treba. Neko je razmislio o ovom slučaju, shvatio ga i zapisao obrazloženje. Zatim je linija ispod koristila >= tamo gde je obrazloženje tražilo >.

Ovo vredi pogledati otvoreno, jer je uobičajeno objašnjenje — niko nije razmislio — dostupno i pogrešno. Razmišljanje je u datoteci. Zakazao je jedan znak, na mestu gde pogrešna i ispravna verzija na prvi pogled izgledaju isto i ponašaju se isto u svakom testu koji ima red za ažuriranje.

Niko nije obmanut

Evo dela koji bi bilo lako izostaviti, a izostavljanje bi ovaj članak učinilo dramatičnijim i manje istinitim.

Stranica ne prikazuje to polje za potvrdu ako red ne postoji. Jedan ekran dalje, u kodu koji crta okvir sa podešavanjima vlasnika, ista tabela se pita prva, a ceo blok se preskače kada upit vrati prazno. Vlasnik brojača bez potvrđene adrese zato nikada ne vidi kontrolu, nikada ne klikne na nju i nikada ne dobije lažnu potvrdu.

Pokvarena provera dostupna je samo direktnim pozivom endpointa sa važećim tokenom. Ko to uradi dobija success: true a podešavanje nije sačuvano. To je stvaran nedostatak, ali uzak.

Zašto je ipak vredno zapisati

Funkcija je bezbedna zbog zaštite koju niko nije zapisao kao zaštitu. Linija koja postoji da je učini bezbednom ne čini je bezbednom. To čini uslov prikazivanja u drugoj funkciji, čiji komentar objašnjava zašto je polje sakriveno — a ne da išta zavisi od toga da ostane sakriveno.

Uklonite ili restrukturirajte taj uslov prikazivanja — razumna stvar pri preuređivanju panela sa podešavanjima — i nedostatak postaje odmah vidljiv, a nigde ništa ne povezuje te dve izmene. Bezbednost je stvarna i slučajna, a slučajna bezbednost je ona vrsta koja nestane tokom nepovezanog posla.

Isti kôd to radi ispravno jednu datoteku dalje. Odgovarajuća funkcija veb-prstena pita da li red postoji, vraća false kada ne postoji i nikada ne izdaje ažuriranje. Ta tabela trenutno ima nula redova, pa ta funkcija vraća false svaki put kada se pozove, što je tačan odgovor.

Opšti oblik

Naredba UPDATE koja ne poklapa nijedan red nije greška ni u jednoj bazi. To je uspešna naredba koja nije uradila ništa, i svaki sloj iznad nje prijaviće uspeh ako nešto ne pita. Dvadeset dve naredbe ovde ne pitaju, i za većinu njih to je u redu: ažuriraju red za koji je zahtev već dokazao da postoji.

Ona koja je morala da pita, pitala je na način koji ne može da zakaže. rowCount() >= 0 nije slaba provera, nego odsustvo provere u kostimu provere — i gora je od nikakve provere, jer sledeća osoba koja čita funkciju vidi da se rezultat ispituje i prestaje da traži.

Izraz rowCount() > 0 pojavljuje se nula puta u ovom kodu. To je broj koji je jednoznakovnu grešku u kucanju pretvorio u nešto što vredi članka: ne da je jednom pogrešno napisano, nego da nigde nije bilo ispravnog primerka sa kojim bi se uporedilo.

Popravljeno 28. avgusta 2026. Endpoint sada pita da li red postoji pre ažuriranja, kao što je funkcija veb-prstena jednu datoteku dalje već radila, i odgovara false kada ne postoji. Očigledna popravka od jednog znaka — poređenje sa većim od nule — prvo je izmerena i odbačena: drajver prijavljuje promenjene redove, a ne poklopljene, pa postavljanje polja za potvrdu na vrednost koju već ima ne menja ništa, i ta verzija bi prijavila neuspeh za operaciju koja je bila u redu. Obe verzije su pogrešne, u suprotnim smerovima.