Store world save variables at characters db

[schell244]

🍰 Pullrequest

Store world persistent variables in characters db.
This enables applying a fresh world db without losing any saved variables.

Refactored storage from a linear vector to an unordered_map for O(1) lookup, replaced the DELETE+INSERT transaction with a single REPLACE INTO, and removed the unused _InsertVariable and LoadVariable functions.

How2Test

• Apply the changes from this PR
• Start the server and verify that save states are now stored in world_persistent_variables in the characters db
• Trigger a world state change (start the Stranglethorn Vale Fishing event and hand in 40 tasty fish)
• Apply a fresh world db and reboot the server → the event should still be completed for that week

Todo / Checklist

• None

[ratkosrb]

World states is already a term that exists, and it's something that's sent to client. We should not have confusing naming like this, because it implies that those are the same world states blizzard sends if you name the table like this, and that is not what it contains. Variables is our own custom indexes and values, not using blizzard's ids for stuff.

[0blu]

variables is too generic, especially in a database like characters.
Maybe something like this:

• persistent_world_data
• persistent_state
• world_persistence
• world_progress
• game_state
• realm_state

or another permutation of these words?

[schell244]

maybe world_persistent_variables?

[shudza]

... and make world database read only.

game_events is written to as well, or am I wrong?

[schell244]

... and make world database read only.

game_events is written to as well, or am I wrong?

Oh yes, you're right, there are querys on game_event_creature and game_event_creature_data. Would probably make sense to move those tables to charcter db as well at some point.

[shudza]

I don't think it makes sense to change only variables then. For example, variables stores stuff like resources for war effort, but the stage it self is stored in game_events. So if the point was to make world db ephemeral/read-only, this would probably cause issues.

[schell244]

Did not experience any issues with that change, but I agree that it makes sense to move the other tables as well, together with the variables. Will add some more changes when I have time.

[0blu]

I don't think it makes sense to change only variables then. For example, variables stores stuff like resources for war effort, but the stage it self is stored in game_events. So if the point was to make world db ephemeral/read-only, this would probably cause issues.

We are focusing on non-admin-command induced changes to the DB.

The current war effort stage is stored in variables at index 30050 and not game_event.
This would be covered by Schell's change. 👍

But (what you probably mean,) game_event has the column disabled which is modified during runtime.
I think we need to come up with a solution to store this column in the charDb.

---

@schell244 Here are some sql snippets you can try to verify your changes.
At the end the server should work with just a read-only world db. (ignoring admin commands to modifying game objects or npcs)

USE world; -- whatever your db name is

-- Creates `root_readonly` user with pw `root` which only has read access to all tables
CREATE USER 'root_readonly'@'%' IDENTIFIED BY 'root';
GRANT SELECT ON *.* TO 'root_readonly'@'%';
FLUSH PRIVILEGES;

-- Grad write permissions to game_event
GRANT INSERT, UPDATE, DELETE ON game_event TO 'root_readonly'@'%';
FLUSH PRIVILEGES;

-- Revoke write permission to game_event
REVOKE INSERT, UPDATE, DELETE ON game_event FROM 'root_readonly'@'%';
FLUSH PRIVILEGES;