Repository navigation
Fix enabling on a fresh PostgreSQL board - #12
Merged
Merged
Conversation
version_1_0_0 inserts the first seven Knowledge Base permission options with explicit ids, which leaves PostgreSQL's sequence for kb_options at 1. version_2_0_30 then let the sequence pick the id for kb_m_change_author, got 1 again, and stopped with a duplicate key, so the extension could not be enabled on a new PostgreSQL board. It now gives the option the next id itself, as version_1_0_0 does. Adds a regression test that builds kb_options the way version_1_0_0 does and runs version_2_0_30 on SQLite, MySQL and PostgreSQL. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
On PostgreSQL, version_1_0_3 creates the search-match unique index as
plain un_mtch. phpBB 3.3's database tools find an index by that name but
drop it as {table}_un_mtch, so version_2_0_31 stopped with "index does
not exist" and a fresh phpBB 3.3 PostgreSQL board could not enable the
extension. version_2_0_31 now drops this table's un_mtch index under
whichever name it really has before creating the four-column one. It
leaves an index of that name on another table alone.
The regression test runs the real migration chain for the table
(version_1_0_0, 1_0_3 with its data step, 2_0_2, 2_0_15, then 2_0_31
twice) on SQLite, MySQL and PostgreSQL.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
bonelifer
added a commit
that referenced
this pull request
Nov 12, 2026
Brings in the fresh-PostgreSQL fix (#12) and the kinerity import (#13). version_2_0_30 now inserts kb_m_change_author with an explicit id, so it gets the same IDENTITY_INSERT wrapper on MSSQL as version_1_0_0, with a test. Both new docs/testing.md sections are kept. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
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
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.
The extension could not be enabled on a new phpBB board that uses PostgreSQL. Two migrations stopped with database errors:
kb_optionsat 1. version_2_0_30 let the counter pick the new option's id, got 1 again, and failed with a duplicate key. It now gives the option the next free id itself, as version_1_0_0 does. This affects phpBB 3.3 and 4.0.un_mtch. phpBB 3.3's database tools find an index by that name but then try to dropphpbb_kb_src_wrdmtch_un_mtch, which does not exist, so the migration failed with "index does not exist". It now drops this table's index under whichever name it really has, then creates the four-column one. An index with that name on another table is left alone. This affects phpBB 3.3 only.Boards on MySQL, MariaDB or SQLite, and boards where these migrations already ran, are not affected. Boards where one of them failed will run the fixed version when the extension is enabled again.
Claude found both errors while testing the kinerity/knowledgebase import on a fresh phpBB 3.3 PostgreSQL board.
Tests: new
tests/kb_options_id_migration_test.php. It buildskb_optionsthe way version_1_0_0 does and runs version_2_0_30, then runs the real migration chain for the search-match table (version_1_0_0, 1_0_3 with its data step, 2_0_2, 2_0_15, and 2_0_31 twice), on SQLite, MySQL and PostgreSQL. Claude checked that both tests fail without the fix (the duplicate key on phpBB 3.3 and 4.0, the missing index on 3.3) and pass with it. The full suite passes on phpBB 3.3.x and master against MySQL 8.0 and PostgreSQL 16 containers (510 tests, none skipped), and the code sniffer is clean with the 3.3 and 4.0 rulesets. After the fix, a phpBB 3.3 PostgreSQL board that had failed at both migrations enabled the extension.Investigated and written by Claude on behalf of William Jacoby (bonelifer).
🤖 Generated with Claude Code