feat(mysqldump): warn when foreign keys are missing due to insufficient privileges

[Soner (shyim)]

The bug

shopware-cli project dump was silently omitting all foreign-key constraints from the schema when the connecting user had read-only privileges scoped only to the target database (e.g. GRANT SELECT ON shopware.*). The dump completed successfully with KEY index entries but no CONSTRAINT … FOREIGN KEY … clauses, producing a schema that imports without referential integrity.

Root cause

internal/mysqldump/schema.go::fetchAllForeignKeys builds foreign-key metadata by joining two INFORMATION_SCHEMA views:

FROM INFORMATION_SCHEMA.KEY_COLUMN_USAGE kcu
JOIN INFORMATION_SCHEMA.REFERENTIAL_CONSTRAINTS rc
    ON kcu.CONSTRAINT_NAME = rc.CONSTRAINT_NAME
    AND kcu.TABLE_SCHEMA = rc.CONSTRAINT_SCHEMA

These two views apply different privilege filters:

• KEY_COLUMN_USAGE rows are visible if the user has any privilege on the child table.
• REFERENTIAL_CONSTRAINTS rows additionally require a privilege on the referenced (parent) table.

A user with SELECT only on the target schema can see every FK column in KEY_COLUMN_USAGE but receives zero rows from REFERENTIAL_CONSTRAINTS. The JOIN therefore returns nothing, every FK silently disappears from the dump, and the user has no way to know it happened.

Reproduced locally against MariaDB 11.8.6 / 12.2.2 with a Shopware schema that has 643 FKs:

Connecting user	KEY_COLUMN_USAGE	REFERENTIAL_CONSTRAINTS	FKs in dump
root	643	643	643
GRANT SELECT ON db.* only	643	0	0

The fix

Before running the FK fetch query, count both sides independently and log a warning if they diverge. The warning quotes both numbers and points at the most likely cause:

WARN  Found 643 foreign key columns in KEY_COLUMN_USAGE but only 0 rows in
      REFERENTIAL_CONSTRAINTS — 643 foreign key constraint(s) will be missing
      from the dump. This usually means the connecting user lacks privileges
      on the referenced tables. Grant SELECT (or REFERENCES) on the parent
      tables and re-run.

Behaviour change:

• Privileged user (e.g. root): silent, dump unchanged.
• Under-privileged user: warning is logged, dump still completes with the same (empty-FK) output as before — but the user now knows why and how to fix it.

This is option B from the discussion: surface the issue without restructuring the query. A future change can switch to a LEFT JOIN that emits FKs without ON DELETE / ON UPDATE rules when rc rows are inaccessible.

Test plan

• go test ./internal/mysqldump/... — all green; sqlmock expectations updated to cover the two new count queries.
• go vet ./internal/mysqldump/ — clean.
• Manual: dump as root against MariaDB 11.8.6 → no warning, 643 FKs in output.
• Manual: dump as GRANT SELECT ON db.* user → warning fires with the correct numbers, dump still completes.