-- Items are identified by vnum, not by name.
--
-- These two tables have stored a TEXT name since 0001, on the reasoning written into
-- ItemCatalog's header: a row refers to an item by the string in it, so a name was the natural key
-- and vnums could be added later as a second index. The reasoning was sound. The premise was not.
--
-- Measured 10 August by tools/area/Measure-NameCollisions.ps1, over the areas area.lst actually
-- loads: 1,756 objects carry 1,756 distinct vnums and only 1,590 distinct short descriptions. 97
-- names are shared by two or more vnums, covering 263 objects -- 15% of every object in the game.
-- `a key` is SEVEN different objects. `a silver dagger` and `a fountain` are four apiece. On the
-- mobile side it is the same shape: `The guildmaster` is fourteen distinct mobs.
--
-- So the string in the row never identified an item, and a saved character's `a key` resolved to
-- whichever key happened to be registered last. Nothing had gone wrong yet only because the mud
-- school set is the only thing ever saved and its names happen to be distinct.
--
-- DEFAULT 0 IS A SENTINEL AND IT IS SAFE HERE, unlike 0004's alignment where zero was a legitimate
-- value that had to be distinguished from "unset". A vnum of 0 is not a legal item: ROM starts area
-- ranges above it, and ItemCatalog.Register throws on a template without one. So 0 unambiguously
-- means "written before this migration".
--
-- THE BACKFILL IS IN C# AND IT IS LAZY, following 0003 and 0004. CharacterMapping.ResolveItem takes
-- the name path for a row with vnum 0 and the next save writes a real vnum back. SQL could not do
-- it: the name-to-vnum mapping lives in the item catalogue, which is built in code from school.are
-- and one day from the importer, and duplicating it here would be a second copy to get wrong.
--
-- That fallback resolves through ItemCatalog.TryGetByName, which REFUSES an ambiguous name rather
-- than guessing. Today nothing is ambiguous among the saved set. The moment an importer runs, it
-- could be -- and then an unbackfilled row is preserved as an unresolved item rather than silently
-- becoming a different object, which is the correct failure.

ALTER TABLE character_inventory ADD COLUMN vnum INTEGER NOT NULL DEFAULT 0;
ALTER TABLE character_equipment ADD COLUMN vnum INTEGER NOT NULL DEFAULT 0;
