## Problem Fourteen columns hold a value this module guarantees has no character outside ASCII — uuids, base64 salts, random tokens, and machine names — and every one of them is declared as if it could hold any Unicode character. A `varchar` column carries a character set. For the bytes on disk that costs nothing, because a `varchar` stores what it uses. It is paid wherever a width has to be *reserved*: in an index, and in the fixed-width rows a sort or a temporary table builds. Under `utf8mb4` that reservation is four bytes per character; under `ascii` it is one. Three of them lead indexes, which is where it is measurable: | Column | Index | Reserved | | --- | --- | --- | | `pdv_subject_key.tenant` | `unique__pdv_subject_key__tenant_owner`, `idx__pdv_subject_key__tenant_master_kek` | 256 bytes, twice | | `pdv_subject_key.master_kek_id` | `idx__pdv_subject_key__tenant_master_kek` | 512 bytes | | `pdv_item.kind` | `idx__pdv_item__owner_kind` | 256 bytes | The rest is a declaration that is simply not true of the value: `item_uuid` is the uuid bound into the AAD at seal time, `passphrase_salt` is `base64_encode()`, `state` is a random anti-CSRF token, `request_id` is a URL-safe random identifier, and `kind`, `tenant`, `master_kek_id`, `cipher_suite`, `scope` and `status` are machine names or one of two constants. ## What makes it safe to say so A column declared ASCII answers a value it cannot hold with a failed write and a message about bytes. So the declaration is only worth making where something refuses such a value first, and today that is an argument about call sites rather than a property of the row: - `item_uuid`, `request_id`, `state`, `passphrase_salt` and `cipher_suite` are produced here and never come from a caller. - `tenant` is `getCurrentTenant()->id()` and `master_kek_id` is a Key entity id — config entity ids, and so machine names by Drupal's own rules. - `kind` has passed `Vault::assertKindExists()`, which throws unless it names a `pdv_item_kind` available in the tenant. - `scope` and `status` are the interface's own constants; the one form that offers a scope offers it as a `#type => select`, which core checks against its own options. That holds for every caller that exists today. It is not a property of the row, though: a caller added later, a migration or a test fixture would meet MySQL rather than an explanation. So the entities that hold these columns check them in `preSave()`, through `AsciiFields::assertAscii()`. The check is exactly what the column assumes — no character outside ASCII — and no more: what shape a kind or a salt has beyond that is each writer's own business, and two rules about one value would be one too many. A caller writing an entity catches it as `EntityStorageException`, which is what storage wraps anything raised in `preSave()` with; the message is carried through. It is deliberately in the entity rather than in `hook_entity_presave()`: these are pdv's own classes, and a global hook fires for every entity type on the site to do the work of five. ## Tests `AsciiColumnsTest` names all fourteen fields and asserts each declares an ASCII column; against the unpatched entities all of them fail. A further case saves a `pdv_item` whose kind carries an accent and asserts the save is refused with a message that says why, and that a machine name beside it still saves. ## Upgrading The declaration reaches a site that installs pdv now. It does not reach one that already has the tables: core refuses to change a populated field's schema, so an existing site keeps the `utf8mb4` columns until something converts them. That is a separate question from this change and is not attempted here. AI-Generated: Yes (Claude Code was used to help draft this issue summary and to write the change and its tests. The test was run against the unpatched entities and seen to fail, and seen to pass with the change.)