Transmission #055: jOOQ-generated Items

jOOQ is now generating schema objects (tables, records, enums, and POJOs) into server/src/generated/java, and the build is wired so generateJooq runs after Flyway migrations. This gives us typed access to the database schema while keeping migrations as the source of truth.

The Item read path is the first endpoint migrated: ItemRepository and ItemHandler now use the generated Item POJO and ITEM table references instead of stringly-typed table/field access, while preserving the existing API JSON shape (snake_case). Integration tests were added/updated to lock in /api/items/{id} behavior, including invalid IDs (400) and missing rows (404).

Loot read path follow-up

The loot table read query was migrated next: LootTableRepository now uses generated LOOT_TABLE, LOOT_TABLE_ENTRY, and ITEM references (with proper aliasing) instead of string field names. Behavior remains the same, and the existing repository + handler tests continue to validate ordering and payload shape.

As a small cleanup, the Gradle build now resolves DB_URL / DB_USER / DB_PASSWORD once up front (rather than via a helper inside the jOOQ DSL), which removes noisy jOOQ configuration warnings during builds.

Cutting obsolete loot bootstrap

An old HarvestableLootBootstrap class was still present and wired into startup, but it referenced UUID-based loot tables and column names that no longer exist in the schema. It also turned out to be redundant once CSV seeding fully populates loot_table and loot_table_entry.

Removing it keeps startup simpler and avoids future confusion during the rest of the jOOQ migration.

Inventory migration and JSON parity

Inventory reads and writes were migrated to generated jOOQ tables as well. One subtle gotcha: generated records expose timestamps as LocalDateTime, which Jackson won’t serialize in our current Javalin setup by default. To preserve API behavior (and keep handlers simple), inventory created_at / updated_at fields are now selected as strings at the query layer.