A verificação que é sempre verdadeira

Neste serviço há 23 instruções UPDATE. Exactamente uma delas verifica se mudou alguma coisa. Essa verificação é:

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

rowCount() devolve 0 quando nenhuma linha coincidiu. Zero é maior ou igual a zero. A verificação passa aconteça o que acontecer.

Para que serve a instrução

Guarda uma caixa: se o dono de um contador quer um resumo semanal por correio. O endereço vive numa tabela à parte, e uma linha só aparece lá depois de alguém ter clicado a ligação de confirmação de uma mensagem que pediu. Quatro contadores têm essa linha. Activos há 2.218.

Para 99,8 % dos contadores o UPDATE não acerta em nada. O ponto de acesso responde success: true e a definição não é guardada, porque não há onde a guardar.

O comentário acima está certo

Três linhas acima, na mesma função:

«Só onde existe um caminho de retorno confirmado. Sem ele não há endereço para onde a carta pudesse ir — e a caixa teria prometido algo que não acontece.»

Está exactamente certo. Alguém pensou neste caso, percebeu-o e escreveu o raciocínio. Depois a linha de baixo usou >= onde o raciocínio pedia >.

Vale a pena olhar isto de frente, porque a explicação habitual — ninguém pensou nisso — está à mão e é falsa. O pensamento está no ficheiro. O que falhou foi um carácter, num sítio onde a versão errada e a certa se parecem à primeira vista e se comportam igual em qualquer teste que tenha uma linha para actualizar.

Ninguém está a ser enganado

Aqui vem a parte que seria fácil deixar de fora, e cuja omissão tornaria este artigo mais dramático e menos verdadeiro.

A página não desenha essa caixa se a linha não existir. Um ecrã adiante, no código que compõe o painel do dono, a mesma tabela é consultada primeiro, e o bloco inteiro é saltado quando a consulta volta vazia. Um dono sem endereço confirmado nunca vê o controlo, nunca lhe toca e nunca recebe a confirmação falsa.

A verificação partida só é alcançável chamando o ponto de acesso directamente com um sinal válido. Quem o fizer obtém success: true e nenhuma definição guardada. É um defeito verdadeiro, e estreito.

Porque vale mesmo assim a pena escrever

A funcionalidade é segura graças a uma guarda que ninguém escreveu como guarda. A linha que existe para a tornar segura não a torna segura. O que a torna é uma condição de desenho noutra função, cujo comentário explica porque é que a caixa está escondida — não que alguma coisa dependa de ela continuar escondida.

Tire ou reorganize essa condição — coisa razoável ao refazer um painel de definições — e o defeito fica visível de imediato, sem que nada em lado nenhum ligue as duas alterações. A segurança é real, é acidental, e a segurança acidental é a que desaparece durante trabalho que nada tem a ver.

O mesmo código faz isto bem um ficheiro adiante. A função equivalente do webring pergunta se a linha existe, devolve falso quando não existe, e nem sequer emite a actualização. Essa tabela tem neste momento zero linhas, portanto a função devolve falso em cada chamada — que é a resposta certa.

A forma geral

Um UPDATE que não acerta em nenhuma linha não é um erro em base de dados nenhuma. É uma instrução bem-sucedida que não fez nada, e todas as camadas acima relatam sucesso enquanto ninguém perguntar. Vinte e duas das instruções aqui não perguntam, e para a maioria isso está bem: actualizam uma linha cuja existência o pedido já provou.

A única que tinha de perguntar perguntou de uma maneira que não pode falhar. rowCount() >= 0 não é uma verificação fraca, é a ausência de verificação disfarçada de verificação — e é pior do que nenhuma, porque o próximo a ler a função vê um resultado a ser inspeccionado e deixa de olhar.

A expressão rowCount() > 0 aparece zero vezes neste código. É esse número que faz de uma gralha algo que merece um artigo: não que tenha sido escrita mal uma vez, mas que não houvesse em lado nenhum um caso correcto com que a comparar.

Corrigido a 28 de agosto de 2026. O ponto de acesso pergunta agora se a linha existe antes de escrever — como já fazia a função do webring um ficheiro adiante — e responde falso quando não existe. A correcção óbvia de um carácter, verificar antes «maior do que zero», foi medida primeiro e descartada: o controlador relata linhas alteradas, não linhas encontradas. Quem põe a caixa no valor que já tem não altera nada — e essa versão teria relatado uma falha para uma operação que estava bem. Ambas as versões estão erradas, em direcções opostas.