Now that jobs & gangs can be modified at runtime, those changes need to be propagated to the playerdata table for any players who hold those groups. To do this we're consuming group updated events, making the needed changes to playerdata, then triggering additional events for playerdata updates to propagate that to the client.
We do not need to remove the player in the case of a group/job/grade being deleted as the database constraints will guarantee that a player can never be in a group or grade that doesn't exist.
Now that jobs & gangs can be modified at runtime, those changes need to be propagated to the playerdata table for any players who hold those groups. To do this we're consuming group updated events, making the needed changes to playerdata, then triggering additional events for playerdata updates to propagate that to the client.
We do not need to remove the player in the case of a group/job/grade being deleted as the database constraints will guarantee that a player can never be in a group or grade that doesn't exist.