Track brewer for each brew

[Tisawesomeness]

Each brew should record who brewed it, expose the brewers to addons, and optionally show the players' names in lore. Note that multiple players can be involved in brewing (one player cooks, another ages).

[Thorinwasher]

Here's my thought on who would be the brewer depending on structure:

Cauldron

The one who extracted the brew (Not the one that added the ingredients)

Barrel

The one who extracted the brew (Both insert and extract works, really)

Distillery

The one who extracted the brew (Both insert and extract works, really)

Other thoughts on this

If you really want to, you can also factor in all actions on the brew. Access could be something like this:

sealed interface UserBrewAction {
    
    StructureType structureType();

    record DistilleryAction(boolean insert) {
        StructureType structureType() {
            return StructureType.DISTILLERY;
        }
    }

    // All other actions
}

class Brew {

    // Actions done by any players on this brew, could be empty set
    Set<UserBrewAction> actions(UUID playername);

    // Actions done by all players
    List<Pair<UUID, UserBrewAction>> actions();

    // Actions done by all players on a step
    List<Pair<UUID, UserBrewAction>> actions(int stepIndex);
}

[Thorinwasher]

Also going to note that finishing this will be easier after #129 is completed (I'm working on it)

[Tisawesomeness]

Both this issue and #156 will need to store extra brew data when serialized to PDC or database. PDC is easy enough, but brews are currently stored in the database as one big JSON array of brewing steps (see BrewSerializer). That's not an extensible format, so I propose:

{
  "version": 0,
  "steps": [...],
  // additional fields...
}

This gives us room to add new fields and migrate the brew format without dealing with db migrations.

[Thorinwasher]

Or introduce two more columns in the brews table

[Thorinwasher]

There's already a versioning system in the whole database, i.e. the version table. We could use that, and bump the database version by one + migrate (Just some alter tables)

[Tisawesomeness]

There's already a versioning system in the whole database, i.e. the version table. We could use that, and bump the database version by one + migrate (Just some alter tables)

I recommended adding to the brew JSON already written to the database in the brew column since storing it in new columns in the database requires updating the four CRUD queries, the Java <-> SQL parsing, and corresponding test code for the barrel_brews, cauldrons, distillery_brews, and mixers. The change to BrewSerializer I have working is tiny by comparison (about 50 lines of Java) and can be tested in isolation.

[Thorinwasher]

I recommended adding to the brew JSON already written to the database in the brew column since storing it in new columns in the database requires updating the four CRUD queries, the Java <-> SQL parsing, and corresponding test code for the barrel_brews, cauldrons, distillery_brews, and mixers. The change to BrewSerializer I have working is tiny by comparison (about 50 lines of Java) and can be tested in isolation.

It's technically only going to be a change in 3 sql statements (including table creation) + one migration statement. Anyhow do what you think is right, I think I'm just a bit salty that I introduced a versioning system to the database, but it's not going to be used 😅 .

[Tisawesomeness]

I found that it was easiest to keep one list of brewers per BrewingStep, so the database format does not need to be updated yet.