mirror of
https://github.com/ZoneMinder/zoneminder.git
synced 2026-10-12 23:03:52 -04:00
Isaac ConnorandClaude Opus 5
faa8d2f20c
Two problems, both in exportsql. The mysqldump command ended with a hardcoded database name, so --export always read from a database called zm whatever ZM_DB_NAME said. It now uses the configured name. The primary keys were then blanked with a regex that replaced everything between VALUES ( and the first quoted string: s/VALUES \((.*?),'/VALUES \(NULL,'/ig That holds only if the id is immediately followed by a quoted value. A MonitorPresets row starts id,ModelId and both are unquoted, so the pattern swallowed the pair into a single NULL and left the row one value short of its columns. On the shipped data that corrupted all 75 preset rows of a 126 row export; the 51 control rows came through intact, which is presumably why it went unnoticed. Replaced with the same parse the import now uses: split the values on top level commas, find the id by column name, and blank just that one, re-emitting the row in the form it arrived in. A row whose value count does not match its table is left alone with a warning rather than rewritten on a guess. Verified against a real dump of the seed data: 126 rows, every one with its id blanked, and not one value-count change -- against 75 corrupted by the old pattern. Round-tripped the export back through --import into an empty database: 51 controls and 74 presets, no broken names, no unresolved control references, and every column identical to the source apart from the one preset row whose name is a duplicate of another, which the import has always collapsed because it keys on Name. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_015Y6FieTwEXuLhhR4e2yiax