Fix: Truncate UUID to fit varchar(16) column when handling duplicate player names

[JobsonMarinho]

Problem

When a duplicate player name is detected, the code was attempting to set the name to the full UUID string (36 characters), which exceeded the database column limit of varchar(16). This caused a MysqlDataTruncation error.

Solution

The fix uses a shortened version by taking the first 15 characters of the UUID and prefixing with '~', resulting in a 16-character string that fits within the database constraint.

Error Fixed

Fixes the error: Data too long for column 'name' at row 1

Changes

• Truncate UUID to 16 characters (~144d3918-0408-3) instead of using full UUID (144d3918-0408-38f1-b631-8a000d6db3d8) when handling duplicate player names
• File changed: src/main/java/net/sacredlabyrinth/phaed/simpleclans/listeners/SCPlayerListener.java

[Copilot]

Pull request overview

This PR addresses a database truncation error that occurred when handling duplicate player names. The fix prevents a MysqlDataTruncation error by truncating the UUID string to fit within the existing varchar(16) database column constraint, rather than attempting to store the full 36-character UUID.

Key Changes:

• Implemented UUID truncation logic (first 15 characters + tilde prefix) when renaming duplicate players
• Added inline comment explaining the varchar(16) constraint
• Maintains existing duplicate detection and resolution workflow

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[RoinujNosde]

Increasing the column size is probably a better solution

[JobsonMarinho]

Increasing the column size is probably a better solution

I think the best approach would be to convert legacy data to support the new account format.

• If the player changes their name but keeps the same UUID, then simply update the name column.
• If the UUID changes but the name stays the same, then update the uuid column instead.

This might not be ideal for every server, but in my case it works well because my network supports premium, cracked and Bedrock players. I already handle this logic across all of my plugins.

However, since SimpleClans is a public plugin, I felt it was better to apply a minimal change by adjusting the name to UUID using:
"~" + duplicate.getUniqueId().toString().substring(0, 15);

This resolved the warnings/errors that appeared in the console and I thought this solution could be beneficial for all SimpleClans users, not just for my specific setup.

[RoinujNosde]

Increasing the column size is probably a better solution

I think the best approach would be to convert legacy data to support the new account format.

* If the player **changes their name but keeps the same UUID**, then simply update the `name` column.

* If the **UUID changes but the name stays the same**, then update the `uuid` column instead.

That would be perfect, indeed.

I tried to implement this once, but had some problems with race conditions IIRC, so I settled for this workaround.

[JobsonMarinho]

@RoinujNosde i completely refactored the player name/UUID handling system to properly manage duplicate and outdated player records in the database. This addresses the MysqlDataTruncation error that was occurring when duplicate players were detected.

What Changed

Instead of trying to rename duplicate players with truncated UUIDs (which was causing database errors), we now implement a comprehensive synchronization system that:

1. Checks for existing records by both name and UUID
2. Handles all edge cases:
   • Same UUID, different name → Updates the name (player changed their name)
   • Same name, different UUID → Updates the UUID (player cracked become premium)
   • Duplicate records with the same name and UUID → Merges them into one
   • Conflicting records (different name AND different UUID) → Intelligently merges the data

Why This Matters

This approach:

• Prevents data loss: Instead of deleting or corrupting player data, we merge conflicting records
• Fixes the truncation error: No more trying to fit UUIDs into name columns
• Handles edge cases: Covers scenarios like name changes, server migrations, cracked→premium transitions, or database corruption
• Preserves player history: Keeps the earliest join date and latest activity timestamps when merging

Implementation Details

• Added findClanPlayerByName() to query players by username
• Created syncPlayerData() to handle all synchronization logic
• Implemented mergeClanPlayers() to intelligently combine duplicate records
• Updated updatePlayerName() to use the new sync system
• All database operations are properly handled with try-catch blocks

I think this is the best solution for handling duplicate records. Does this approach align with your vision for SimpleClans? Is there any suggestion or improvement you’d like to see?

[JobsonMarinho]

[JobsonMarinho]

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 13 comments.

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[Copilot]

Pull request overview

Copilot reviewed 2 out of 2 changed files in this pull request and generated 6 comments.

Comments suppressed due to low confidence (1)

src/main/java/net/sacredlabyrinth/phaed/simpleclans/listeners/SCPlayerListener.java:179

• @param tag "cp" does not match any actual parameter of method "updatePlayerName()".

     * @param cp to update

---

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

[JobsonMarinho]

@RoinujNosde can u review it?

[JobsonMarinho]

@RoinujNosde I reversed the line breaks, anything else?

[RoinujNosde]

This is calling database code in the main thread, it's going to cause lag.

[RoinujNosde]

This will never happen. The object is already created here:

SimpleClans/src/main/java/net/sacredlabyrinth/phaed/simpleclans/listeners/SCPlayerListener.java

Line 86 in 90b7378

ClanPlayer cp = plugin.getClanManager().getCreateClanPlayer(player.getUniqueId());