AST driver fails on bare `0x` empty-BLOB literal in INSERT (MariaDB dump from Wordfence)

[wormeyman]

Summary

The AST-based MySQL→SQLite translator (wp sqlite import --enable-ast-driver) rejects MariaDB's bare 0x empty-binary-literal in INSERT statements. Hex literals with content (0xDEADBEEF) translate correctly; the zero-digit form does not.

This blocks .wpress (All-in-One WP Migration) imports of any site that has Wordfence installed - Wordfence's wp_wfconfig table stores empty BLOBs that mysqldump emits as 0x.

Reproducer

CREATE TABLE wf_demo (
  name varchar(100) NOT NULL,
  val  longblob,
  autoload varchar(20) NOT NULL DEFAULT 'yes',
  PRIMARY KEY (name)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;

INSERT INTO `wf_demo` VALUES ('with_data', 0xDEADBEEF, 'yes');
INSERT INTO `wf_demo` VALUES ('empty',     0x,         'yes');

Pipe through wp sqlite import --enable-ast-driver. The first INSERT succeeds, the second errors:

Error: Could not execute statement: INSERT INTO `wf_demo` VALUES ('empty', 0x, 'yes')

Expected

0x (zero hex digits) is valid MariaDB/MySQL syntax for an empty binary string. SQLite's BLOB literal form is X''. The translator should emit X'' (or '') for 0x exactly as it does for the non-empty case.

Real-world impact

Any .wpress archive from a Wordfence-using site fails Studio's studio site import partway through:

Database import failed: Error: Could not execute statement:
INSERT INTO `wp_wfconfig` VALUES ('bannedURLs', 0x, 'yes')

In Studio's case the importer aborts on first error, leaving the SQLite DB partially populated (schema and ~half the tables present, no theme/plugins activated, broken site).

Workaround that worked

Same-byte-count binary patch on the .wpress (uncompressed format, so database.sql is in plain bytes inside the archive):

data = open(path, 'rb').read().replace(b",0x,", b",'',")
open(path, 'wb').write(data)

48 occurrences in my case. Substituting '' (empty string) instead of X'' keeps the byte count identical and avoids re-packing the wpress headers. After patching, studio site import runs end-to-end and the site comes up correctly.

Suggested fix

Two reasonable spots:

1. Lexer/parser: treat 0x followed by zero hex digits as a valid empty BLOB literal token, emitting X''.
2. Or in the INSERT-row codegen: if a hex-literal token has empty content, emit X'' rather than passing the original 0x through.

Either is a tiny change relative to writing it out as a workaround in every downstream tool (Studio, Local, etc.).

Related precedent

Same shape as Automattic/studio#2302, where MariaDB's DEFAULT (now()) in CREATE TABLE wasn't recognized by the AST driver. It was fixed in sqlite-database-integration v2.2.17 and rolled into Studio via Automattic/studio#2512. This 0x empty-BLOB issue feels like the same family of "valid MariaDB tokens the AST driver doesn't yet model."

Environment

• sqlite-database-integration v3.0.0-rc.3 (as bundled in Studio 1.8.0)
• Source DB: MariaDB 11.4.7 (mysqldump output via All-in-One WP Migration 7.105)
• Reproduces independently of Studio - it's purely a translator issue triggered by wp sqlite import --enable-ast-driver.

[wormeyman]

Update: traced the upstream cause. The bare 0x token is emitted by All-in-One WP Migration's dumper at class-ai1wm-database.php:2189 (v7.105), where '0x' . bin2hex($input) produces just '0x' when the input is an empty string. Stock mysqldump --hex-blob and phpMyAdmin both emit '' for empty BLOBs - this is specific to ai1wm.

Reported to ServMask: https://wordpress.org/support/topic/bug-bare-0x-for-empty-blob-makes-wpress-unreadable-outside-ai1wm/

This issue still stands as a robustness fix on the translator side - an empty hex literal should round-trip to X'' even though it's not strictly valid input - but the bulk of affected users will be unblocked once ai1wm patches the dumper.