funman300
8b1081019f
CI / Build, lint & test (push) Successful in 3m21s
Core could only own players. Everything else a FUT club holds — managers, staff, consumables, kits, badges, balls, stadiums — had no representation, so the only way to show one to a client was to synthesise it on read. That is the failure mode this commit exists to make impossible: read authority, write authority and persistent ownership authority are now the same rows. MODEL. There is deliberately NO parallel items table. A manager, a consumable, a kit and a player are all rows in `owned_cards`, differing only by a new game-INDEPENDENT `content_kind` (player|manager|staff|consumable|kit|badge|ball| stadium|misc). A game adapter translates its own taxonomy — FIFA 17's `cardsubtypeid` and resource ranges — into one of those tokens before ownership reaches Core; no game's numerics land here. Ownership stays INSTANCE-based: `card_id` is the definition, `id` is the instance, and two copies of one definition remain two rows. `quantity` is a nullable per-instance attribute, not a replacement for the instance. The real profile settles this: its 17 consumables are instance-based and only SOME carry a wire `amount` (observed 1,2,4,5,10,15), while two copies of definition 5003068 exist as two distinct instances. So NULL means "not a stack" and a positive integer is the stack size; collapsing instances into counts is forbidden by the model. ACTIVE DESIGNATIONS. Migration 0024's two-slot kit table becomes `club_active_items` over the five slots that correspond exactly to the client's recovered equipped-state vocabulary (activeBadge 100, activeHomeKit 101, activeAwayKit 102, activeBall 103, activeStadium 104). There is no activeLeagueLogo or activeMisc token, so those kinds correctly get no slot. The invariants are schema-enforced rather than conventional: PK(club_id, slot) allows at most one item per role, `owned_card_id UNIQUE` makes "the same card is both home and away kit" unstorable, and ON DELETE CASCADE means a quick-sold or consumed item cannot be projected back as active. 0024's trigger is preserved in semantics — and dropped EXPLICITLY before its table, because it lives ON `owned_cards`, so DROP TABLE would have orphaned it and broken every later ownership transfer. It still exists because the market moves ownership by UPDATE, which no foreign key can observe. CONSUMABLE ACTIONS. `services/consume.rs` is one transaction primitive — validate source ownership and kind, validate target, mutate, consume the source exactly once, commit — guarded by `UNIQUE(profile_id, action_identity)` in migration 0027, the same discipline as `match_completions`. It supports both deleting the row and decrementing a stack, chosen by the caller, inside the one transaction and the one replay guard. It deliberately contains NO category formulas: an unreversed effect must not be invented, so callers supply the mutation and category validation stays explicit. `/club/kits` is replaced by slot-generic `/club/active-items`. `get_collection` now carries `content_kind` and `quantity`, accepts a `content_kind` filter, and — importantly — stops dropping an owned card with a missing definition silently: the envelope reports `owned_rows`, `unresolved_items` and the offending definition ids. That silent `filter_map` is the documented cause of a club that looks empty while the rows are all present. Verified against a REAL populated club, not a fixture: the production snapshot (migration 19) is copied to a tempdir, migrated to 0024, given two kit designations on real owned instances, then migrated to head. 1986 owned rows survive as content_kind='player', both designations land in `club_active_items`, no row gains a quantity, and the old table is gone. 258 tests pass, clippy clean.
40 lines
2.1 KiB
SQL
40 lines
2.1 KiB
SQL
-- Generic owned-content classification on the EXISTING ownership table.
|
|
--
|
|
-- Core owns ONE instance-based ownership model for every kind of owned content.
|
|
-- There is deliberately no parallel "items" table: a manager, a consumable, a
|
|
-- kit and a player are all rows in `owned_cards`, differing only by
|
|
-- `content_kind`. Two copies of one definition remain TWO rows (instance-based
|
|
-- ownership: `card_id` is the definition, `id` is the instance).
|
|
--
|
|
-- `content_kind` is a game-INDEPENDENT vocabulary. Game adapters translate their
|
|
-- own taxonomy (e.g. FIFA 17 `cardsubtypeid` / resource ranges) into one of these
|
|
-- tokens before ownership reaches Core; a game's numeric ids NEVER land here.
|
|
--
|
|
-- BACKFILL: none needed — every pre-existing row is a player card, which is
|
|
-- exactly the column DEFAULT, so the ALTER backfills all existing ownership as
|
|
-- 'player' in place. (Verified against a real populated club snapshot: 1986
|
|
-- owned rows, all players.)
|
|
ALTER TABLE owned_cards ADD COLUMN content_kind TEXT NOT NULL DEFAULT 'player'
|
|
CHECK (content_kind IN (
|
|
'player', 'manager', 'staff', 'consumable',
|
|
'kit', 'badge', 'ball', 'stadium', 'misc'
|
|
));
|
|
|
|
-- Optional stack count for content that is owned as an instance CARRYING a
|
|
-- count rather than as a bare instance.
|
|
--
|
|
-- Evidence (real profile, 1995 owned items): consumables are instance-based with
|
|
-- an OPTIONAL count — some carry a wire `amount` (observed 1,2,4,5,10,15), some
|
|
-- omit the key entirely, and two copies of one definition exist as two distinct
|
|
-- instances. So a count is a per-instance ATTRIBUTE, never a replacement for the
|
|
-- instance: NULL means "not a stack", a positive integer is the stack size.
|
|
-- Collapsing instances into counts is forbidden by the ownership model above.
|
|
ALTER TABLE owned_cards ADD COLUMN quantity INTEGER
|
|
CHECK (quantity IS NULL OR quantity >= 1);
|
|
|
|
-- Every club projection reads one kind at a time (players for the squad, kits
|
|
-- for the club room, consumables for the item list), so the club+kind pair is
|
|
-- the hot access path.
|
|
CREATE INDEX IF NOT EXISTS idx_owned_cards_club_kind
|
|
ON owned_cards(club_id, content_kind);
|