fix(DB): Use creature.id column instead of nonexistent id1/id2/id3#480
Conversation
The creature spawn table uses a single `id` column. Commit #114 switched all module creature queries to `id1`/`id2`/`id3`, which do not exist in the acore_world.creature schema, so the world auto-updater aborted with "Unknown column 'id1' in 'where clause'". Revert id1 -> id across all creature UPDATE/DELETE/SELECT statements and drop the id2/id3 columns (and their values) from the creature INSERTs. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
|
Caution Review failedThe pull request is closed. ℹ️ Recent review info⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Plus Run ID: 📒 Files selected for processing (29)
📝 WalkthroughWalkthroughAcross 29 SQL migration files spanning Brackets 0 through 80_4_1, all references to the Changesid1 → id Column Fix Across Progression SQL Migrations
Estimated code review effort🎯 2 (Simple) | ⏱️ ~10 minutes Poem
✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
Problem
Applying the module fails on world DB import:
The
acore_world.creaturespawn table uses a singleidcolumn (noid1/id2/id3). Commit "Change id to id1 for creature queries" (#114) rewrote every module creature query to theid1/id2/id3schema, which this core does not have, so the world auto-updater aborts.Fix
id1->idin all creatureUPDATE/DELETE/SELECTstatements (29 files).id2/id3from the creatureINSERTcolumn lists and remove the corresponding0, 0values from each row (brewfest, love_in_air, kazzak).zoneId/areaIdand the rest of the columns already exist in the schema and are unchanged.Verification
Validated against a live
acore_worldDB: the originally failingUPDATEand a fixedINSERT(in a rolled-back transaction) both execute without error. Column count matches value count for every editedINSERT.Summary by CodeRabbit