fix(schema): seven CREATE TABLE statements described a table the database never stored (#1087 passo 8) - #1096
Merged
Merged
Conversation
…base never stored (#1087 passo 8) The idempotence gate measured 14 statements dbDelta wanted to ALTER against tables it had just created from those very statements. Seven are fixed here; the remaining seven are one open question, recorded as such. **Display width — 9 statements, 20 changes.** The statements wrote `int unsigned` while MariaDB stores `int(10) unsigned`. This looked like a trade-off between servers and is not: WP core's dbDelta ignores a width-only difference on MySQL 8.0.17+ and *explicitly not* on MariaDB ("Note: This is specific to MySQL and does not affect MariaDB"), so writing the width is correct on both — and is what WP core writes in its own schema. The three incremental ALTERs that spelled the same columns differently are aligned with the CREATE. **`ffc_reregistrations.audience_id`.** The migration still declared a column and index that `ReregistrationActivator` drops right after, having moved the relationship to a junction table: on a fresh install the column was created and destroyed in the same activation, and the declaration described a table that never exists. Correcting the record from the issue comment: this was NOT a per-activation cycle, because `create_reregistrations_table()` is guarded by `table_exists()`. **`KEY auth_code` on two tables.** `upgrade_auth_code_unique_constraints()` drops every non-unique index on the column and adds `UNIQUE INDEX uq_auth_code`, on `ffc_submissions` and `ffc_reregistration_submissions` alike, so the plain KEY these statements declared never survived. They now declare the UNIQUE the code actually creates — the same shape as `validation_code` in the self-scheduling tables. Both plain KEYs were added by passo 4 and passo 5 of this same issue. **Left open on purpose: `json`, 7 statements.** MariaDB implements JSON as LONGTEXT plus a CHECK, so those columns drift there forever; declaring `longtext` would fix MariaDB and, on MySQL 8, convert a native `json` column once — data survives, validation does not. Which server the schema describes is a product decision, not something a scan settles. dbDelta offers no relief: its `$text_fields`/`$blob_fields` leniency lists neither type. The baseline shrinks from 14 statements / 33 changes to 7 / 10. That prediction is not measured — there is no MariaDB in the dev container — so if it is wrong the gate fails and prints the exact block to paste. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_012XWx9qJdjZdAq8crxM9GCU
rpgmem
marked this pull request as ready for review
September 7, 2026 03:36
rpgmem
enabled auto-merge (squash)
September 7, 2026 03:37
8 tasks
Coverage Report for CI Build 34079836679Warning Build has drifted: This PR's base is out of sync with its target branch, so coverage data may include unrelated changes. Warning No base build found for commit Coverage: 89.969%Details
Uncovered ChangesNo uncovered changes found. Coverage RegressionsRequires a base build to compare against. How to fix this → Coverage Stats
💛 - Coveralls |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
O gate de idempotência do passo 7 mediu 14 declarações que o
dbDeltaqueria alterar contra tabelas que ele mesmo acabara de criar a partir daquelas mesmas declarações. Sete são corrigidas aqui; as outras sete são uma pergunta em aberto, registrada como tal.int unsignedenquanto o MariaDB gravaint(10) unsigned. Isto parecia um trade-off entre servidores e não é: odbDeltado WP core ignora diferença só de width no MySQL 8.0.17+ e explicitamente não no MariaDB (Note: This is specific to MySQL and does not affect MariaDB). Escrever o width está certo nos dois — e é o que o WP core faz no próprio schema. As 3 declarações incrementais que grafavam as mesmas colunas de outro jeito foram alinhadas aoCREATE.ffc_reregistrations.audience_id. A migration ainda declarava coluna e índice que oReregistrationActivatorderruba logo depois, desde que a relação virou tabela de junção: numa instalação nova a coluna nascia e morria na mesma ativação, e a declaração descrevia uma tabela que nunca existe.KEY auth_codeem duas tabelas.upgrade_auth_code_unique_constraints()derruba todo índice não-único da coluna e adicionaUNIQUE INDEX uq_auth_code, tanto emffc_submissionsquanto emffc_reregistration_submissions— oKEYsimples que essas declarações traziam nunca sobrevivia. Passam a declarar o UNIQUE que o código realmente cria, mesma forma que oCLAUDE.mdjá registra paravalidation_code. Os doisKEYforam adicionados pelos passos 4 e 5 desta mesma issue.Baseline: 14 declarações / 33 mudanças → 7 / 10.
Deixado em aberto de propósito:
json, 7 declaraçõesO MariaDB implementa
JSONcomoLONGTEXTmais um CHECK, então essas colunas drifta lá para sempre. Declararlongtextlimparia o MariaDB e, no MySQL 8, converteria uma colunajsonnativa emlongtextuma vez — os dados sobrevivem, a validação não. Qual servidor o schema descreve é decisão de produto, não coisa que uma varredura resolve. OdbDeltanão oferece saída: suas listas$text_fields/$blob_fieldsnão incluem nenhum dos dois tipos.Duas correções do que eu afirmei antes
dbDeltadiz o contrário, e é por isso que esta correção existe.audience_idera "um ciclo cria/derruba por ativação, indefinidamente". Não é —create_reregistrations_table()tem guardatable_exists(), então numa instalação estabelecida odbDeltanunca recriava a coluna.Type of change
Nenhuma instalação existente muda: todos os
CREATE TABLEtocados são protegidos portable_exists(), então só uma ativação em banco vazio os executa.Test plan
vendor/bin/phpunit— suíte completa verde (7667 testes, 21980 asserções)vendor/bin/phpunit --filter 'ActivatorSql|SchemaAgreement|CreateStatementsParser'— 11 testeswp-admin/includes/upgrade.php), não de memóriafresh-installfalha e imprime o bloco exato para colar.Checklist
CHANGELOG.mdatualizado ([Unreleased]→Fixed)CLAUDE.mdatualizado — o gate novo e as três lições contra-intuitivas da primeira mediçãoReferencia #1087 (passo 8). A issue segue aberta pelas 7 declarações
jsone pela consolidação das declarações duplicadas.🤖 Generated with Claude Code
https://claude.ai/code/session_012XWx9qJdjZdAq8crxM9GCU
Generated by Claude Code