Converting a pre existing database to use UUIDs

Background

Historically, a player's name was fixed and was the only way to uniquely identify the player. In April 2014, Mojang switched to using a universally unique identifier(UUID) to internally identify players. In February 2015, they began to allow players to change their names. LogBlock switched to using the UUID in mid February

LogBlock internals

LogBlock uses a (non-universal) local unique identifier called the playerid to record player actions. Prior to the UUID change, when a player joined the server, their name would be looked up in a list and matched to their playerid, and each action would be recorded using that id. Now, it's their UUID that is matched. The list still stores their last known name, so that lookups have something friendly to show the admins. So for all intents and purposes, a player's actions are tied to their playerid. There are also some non-player actors in the table (for example, to record when an Enderman moves a block) - these are given a fake UUID

Migration process

If you were using an old (pre-UUID) version of LogBlock and upgrade to a newer version, the player table needs to be updated to include the UUID. Mojang provide a service where you can submit a list of (current) names and it will supply the UUIDs associated with them. On first startup, the LogBlock will attempt to query this service.

However, if the player has changed their name, meaning the name recorded in the database is no longer valid, LogBlock will not be able to find the UUID associated with that playerid. The record will be given a "dummy" UUID, similar to that given to non-player actors. When that player logs in with their new name, it will be assigned a new record, their UUID will be recorded, and all subsequent actions will be recorded under that record. Their old actions will remain, static, under the record that could not be migrated. A worse problem is, if a new user took an older user's name before migration, LogBlock will assume they are the same person, and assign the pre-existing record to the new user's UUID

Recommendation

Given the amount of time that's passed since name changes were introduced, if you are switching to using a UUID-aware version of LogBlock (1.9 or higher) and believe the above issues will cause confusion, you should strongly consider wiping your logging database