Adapt SQLite support to sqlite-database-integration 3.0 - #344
Conversation
The 3.0 release of the SQLite drop-in replaced the old translation layer with the MySQL-on-SQLite driver, which changes three things the Behat suite relied on. All `SQLite` matrix jobs went red as a result, while the MySQL/MariaDB jobs stayed green. `SHOW TABLES` now sorts by table name and honors a `WHERE` clause, so `wp db tables` returns the same alphabetically sorted list it returns on MySQL. The `@require-sqlite` variants of the two `db tables` scenarios only differed from their MySQL counterparts in that ordering, so drop the duplicates and let the original scenarios cover both database types. `SHOW COLUMNS` now reports MySQL types instead of the underlying SQLite storage types, and no longer quotes an absent default, so `db columns` reports `date`/`text` with an empty default rather than `TEXT`/`''`. Finally, the driver rejects multi-queries, and a query with redundant trailing semicolons parses as one. The MySQL client silently ignores the empty statements they produce, so trim them in the SQLite query path to keep `wp db query` behaving the same on both. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MXbmdB7hvQ2jwEe64h6s5K
`columns()` dropped `Extra` from the output on SQLite because the old SQLite drop-in did not return that field from `SHOW COLUMNS`. The MySQL-on-SQLite driver in sqlite-database-integration 3.0 returns the full MySQL-compatible column set, so the workaround now hides information that is available, notably `auto_increment`. With `Extra` restored, the SQLite variant of the `db columns` scenario expects exactly what the MySQL variant does, so drop the duplicate. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01MXbmdB7hvQ2jwEe64h6s5K
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (4)
💤 Files with no reviewable changes (2)
📝 WalkthroughWalkthroughThe database commands now normalize and validate SQLite queries, use consistent column output across database types, and update feature coverage by removing SQLite-specific scenarios and adjusting requirement tags. ChangesDatabase command updates
Estimated code review effort: 2 (Simple) | ~10 minutes Merge Risk: ⚪ Minimal · up to The PR aligns SQLite table, column, and query behavior with the updated driver and removes redundant backend-specific scenarios; no actionable merge-blocking risk remains beyond normal checks and review. Suggested labels: Suggested reviewers: 🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✨ Finishing Touches📝 Generate docstrings
🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
github-actions
Bot
added
bug
command:db-columns
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
|
All 48 Behat jobs are green, including every SQLite job that was failing before this PR. The one red check is The behavior itself is covered: the trailing-semicolon path is exercised by Generated by Claude Code |
Every
SQLitejob in the matrix has been failing since sqlite-database-integration 3.0 replaced the old translation layer with the MySQL-on-SQLite driver. The MySQL/MariaDB jobs are unaffected. Example run: https://github.com/wp-cli/db-command/actions/runs/31762124942Three driver behaviors changed. Each was verified by driving the 3.0 driver directly against an in-memory SQLite database rather than inferred from the CI output.
SHOW TABLESis now sorted and honorsWHEREThe translation ends in
ORDER BY table_name, and theWHERE ... IN (...)clause thatUtils\wp_get_table_names()builds is now applied.wp db tablestherefore returns the same alphabetically sorted list on SQLite as it does on MySQL.The
@require-sqlitevariants of the twodb tablesscenarios differed from their MySQL counterparts only in that ordering, so this drops the duplicates and lets the original scenarios cover both database types.Note that the
array_intersect()SQLite workaround in wp-cli'swp_get_table_names()is now a no-op, but it still does real work against the 2.x drop-in, so it is best left alone until 3.0 is a hard requirement. No framework change is needed here.SHOW COLUMNSreports MySQL types and theExtrafieldTypes come back as
date/textrather than the underlying SQLite storage types, and an absent default isNULLrather than a quoted empty string. This was verified to hold under the default SQL mode, wpdb's filtered mode, and an empty mode, so it does not depend onsql_mode.The driver also returns the
Extrafield now.columns()dropped it on SQLite because the old drop-in did not provide it; that workaround now hides information that is available, notablyauto_increment, so it is removed. WithExtrarestored the SQLitedb columnsscenario expects exactly what the MySQL one does, so that duplicate goes too.Multi-queries are rejected
wp db query "CREATE TABLE ... );;"fails withMulti-query is not supported.— the stray second semicolon parses as an empty second statement. The MySQL client silently ignores it, which is why that line sat unnoticed indb-columns.feature.Rather than edit the test, this trims redundant trailing semicolons in the SQLite query path so
wp db querybehaves the same on both backends. The;;stays in the feature file as regression coverage.Not addressed here
wp db exportincludes the driver's internal_wp_sqlite_*tables in the dump. That looks like something to strip, but excluding them is worse: a round-trip through a stripped dump reconstructs the schema lossily, turningbigint(20) unsignedintoint,datetimeintovarchar(65535),longtextintotext, andNOT NULLcolumns into nullable ones. On tables with an auto-increment column, every column additionally comes back markedauto_incrementand all defaults are lost, which looks like a bug worth reporting upstream.Since
wp db exporton SQLite emits asqlite3 .dumpwhose only real consumer iswp db importinto another SQLite install, keeping the information schema is the correct behavior. The existing_mysql_data_types_cacheexclusion is dead code under 3.0 and harmless.One inconsistency does remain:
wp db export --tables=...builds its exclusion list as "everything not requested", which sweeps the internal tables out, so targeted exports are lossy while full exports are not. Happy to address that separately if wanted.Generated by Claude Code
Summary by CodeRabbit
Bug Fixes
Extrafield for SQLite output.Tests