Entity radius purge - #1030
Open
tonyjamesstark wants to merge 9 commits into
Open
Entity radius purge#1030tonyjamesstark wants to merge 9 commits into
tonyjamesstark wants to merge 9 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
On SQLite, /co purge r:#world i:<block> built the retain condition for world-scoped tables without checking the block restriction, so it purged co_container, co_chat and the other world-scoped tables in that world although a block restriction should leave them untouched. The entity_container/entity_interaction branch and the MySQL path already check it. 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
/co purge rejects a numeric radius, but the check only saw the radius when the sender had a location. From the console, /co purge t:30d r:50 parsed no radius and no world, so it ran as a server-wide purge. The radius is now also parsed against a placeholder location, so it is rejected for every sender. r:#world is unaffected. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
PurgeFilter now builds the purge condition for every table, and the SQLite copy, the SQLite recovery path and the MySQL/DuckDB delete all use it instead of three hand-built copies. Behavior is unchanged; the block restriction check that the previous commit added to the SQLite copy is part of the shared condition. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
/co purge rejected entity types and actions, so mob farm kill logs could only be removed together with all other data. New arguments on SQLite, MySQL and DuckDB: - a:kill purges only entity kill rows. - i:<entity> purges kills of those entity types; it can be combined with block types. - e:<entity> keeps kills of those entity types while purging the rest. Each purged kill also removes its co_entity row. a:kill with block types, entity types in both i: and e:, e: with only block types in i:, non-entity exclusions and entity filters on ClickHouse are rejected. Any a: value other than a kill alias is rejected instead of falling through to an unrestricted purge. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
/co purge rejected any numeric radius, so kills of one entity type could only be purged across a whole world. A radius is now accepted when the purge is restricted to co_block rows with i: or a:kill, for example /co purge t:30d r:50 i:zombie. r:50x10 also limits the height. The radius becomes an x/y/z range in the co_block condition. co_entity rows follow the purged kill rows, so no entity data is orphaned, and the (wid,x,z,time) index already covers the range. Other tables are left untouched, as with any restricted purge. Rejected: a radius without i: or a:kill, WorldEdit selections, radius purges on ClickHouse, and a numeric radius from the console (it has no location, as in the console radius fix merged into this branch). Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
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
2 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.
This PR depends on PR 5. Upstream rejects any numeric radius in
/co purge, so kills of one entity type can only be purged across a whole world today. This PR accepts a radius when the purge is already limited toco_blockrows withi:ora:kill, for example/co purge t:30d r:50 i:zombie.r:50x10also limits the height.co_blockcondition.co_entityrows are purged through the kill rows they belong to, so no entity data is orphaned. The existing(wid,x,z,time)index covers the range, so no schema change is needed.i:ora:killis still rejected, because upstream appears to reject world-wide radius purges on purpose.PR 6 also depends on PR 1b and contains its commit. PR 6 replaces the blanket radius rejection, so it keeps its own check that rejects a numeric radius from the console.
Tests (local, not committed): with kills at several coordinates, a 50-block radius deletes only the zombie kills inside it and their entity data. A radius centered 1000 blocks away deletes nothing, and a height limit above the kills deletes nothing.
a:killwith a radius deletes every kill inside it. The tests passed on SQLite, DuckDB and MySQL 8. With the radius bounds removed, all five radius tests fail.