Repository navigation
Fix orphaned entity data - #1027
Closed
tonyjamesstark wants to merge 6 commits into
Closed
tonyjamesstark wants to merge 6 commits into
tonyjamesstark wants to merge 6 commits into
Conversation
co_entity has no world column, so /co purge r:#world deleted the kill rows in co_block but kept every co_entity row. Those blobs became orphans that no later purge removed. - SQLite: copy only the co_entity rows that a retained kill row still references. This also drops orphans left by earlier purges. - MySQL/DuckDB: delete the co_entity rows of the kill rows a world purge removes, before co_block is purged. MySQL uses a join so MariaDB and MySQL 5.7 do not run a dependent subquery. Global purges keep the cheaper time-based delete, which is equivalent. If MySQL stops between the two deletes, running the same purge again removes the remaining kill rows. Player kills use the kill action with type 0 and a user id in data, so they are never treated as co_entity references. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
MySQL deletes in place, so co_entity rows orphaned by earlier world purges stay until something removes them. With #optimize, delete every co_entity row that no kill row references, through a temporary table of referenced ids (avoids an anti-join on the unindexed co_block.data), then let OPTIMIZE reclaim the space. Failures are reported like the table loop, so the entity_spawn link cleanup still runs. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
Contributor
|
Before merging, please address two MySQL safety issues:
|
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The #optimize orphan sweep snapshots the co_entity ids that kill rows reference, then deletes every row missing from the snapshot. Another installation sharing the database could commit a kill between the two statements and lose its entity data. The sweep now only deletes rows inside the purge time range. A kill always writes its co_entity row with the current time, and a purge range ends at least 24 hours ago, so a concurrent kill never matches. A world purge deletes the entity data of the purged kills and then the kill rows. On MySQL a failure or cancellation between the two left kept kill rows without their rollback data. Both deletes now run in one transaction. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
A SQLite purge dropped every co_entity row no kill referenced, including rows newer than the purge range, and counted them as deleted. It now only removes unreferenced rows inside the range, like the MySQL #optimize sweep. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Contributor
|
Accepted, but merge conflicts must be resolved. |
…ty-data # Conflicts: # src/main/java/net/coreprotect/command/PurgeCommand.java # src/main/java/net/coreprotect/database/PurgeFilter.java
Contributor
|
These changes were included in #1030. |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
3 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
co_entitystores the entity state for each mob kill, and it is referenced byco_block.datawhereaction = 3andtype <> 0. It has no world column, sor:#worldpurges delete the kill rows but never theco_entityrows. Those blobs become orphans that no later purge removes.co_entityrows that a retained kill row still references. This also removes orphans that earlier purges left.co_entityrows of the purged kill rows, beforeco_blockis purged. MySQL uses a multi-tableDELETE ... JOIN. On MySQL 8,EXPLAINshows it readsco_blockthrough thewidindex and deletes by primary key. Global purges keep the existing time-based delete.#optimize: the purge deletes every orphanedco_entityrow through a temporary table of referenced ids. This needs theCREATE TEMPORARY TABLESprivilege. A failure is reported the same way as the table loop, and the rest of the purge still runs.Player kills (
type = 0,data= user id) are never treated asco_entityreferences.Removing orphaned rows now also means the v26 migration of SQLite and MySQL entity data converts fewer rows.
authored and verified with claude