enhancement
major
minor
defect
critical
major
minor
major
#30115
delete-module / delete-class do not clean up hasWrapperAttValue data
When deleting modules (delete-module) or classes (delete-class) in a migration, the metadata rows in META_ATTRIBUTE are removed correctly, but the corresponding data rows in ` HAS_WRAPPER_ATT_VALUE ` (and, if applicable, other association tables) remain in the database as orphaned entries.
Cause
- DeleteTLModuleProcessor collects types, TypeParts, generalizations, and specializations and deletes them directly from the metadata tables using ` deleteModelParts() ` without falling back on ` DeleteTLReferenceProcessor `.
- DeleteTLClassProcessor calls Util.deleteTLType(), which deletes the metadata and synthetic association types but also does not execute a DELETE FROM HAS_WRAPPER_ATT_VALUE.
- Only the explicit DeleteTLReferenceProcessor (<delete-reference>) deletes the data rows from the association table (default: hasWrapperAttValue).
Impact
After a migration that deletes modules or classes with stored reference attributes, orphaned rows remain in HAS_WRAPPER_ATT_VALUE whose META_ATTRIBUTE_ID refers to META_ATTRIBUTE entries that no longer exist. Functionally, this has no direct effect, since the rows are no longer accessed at runtime, but it burdens the database with dead weight.
Expected Behavior
`delete-module` and `delete-class` should also remove the corresponding data rows in the association table for each deleted reference—ideally by reusing the logic from ` DeleteTLReferenceProcessor`.
Addendum: Data for Deleted Instances
If the `type-table` option is set for `delete-class`, `DeleteTLClassProcessor` deletes the instances of the class from the object table (`DELETE FROM <type-table> WHERE BRANCH = ? AND TYPE_ID = ?`). However, the data associated with these instances remains:
- Flex attributes: The rows in FLEX_DATA (key TYPE = table name, IDENTIFIER, BRANCH) for the deleted instances are not removed.
- Reference values: Rows in hasWrapperAttValue (or the other association tables) whose SOURCE is a deleted instance are not removed—not even for references to other, undeleted classes.
`delete-module` has no equivalent to ` type-table`; the instances of the classes in a deleted module remain there in their entirety.
Expected: When instances are deleted from the object table, their Flex attributes in FLEX_DATA and the rows originating from them in the association tables are also deleted. delete-module should be able to delete the instances of its classes along with this data in the same way.
Examples in the code:
- DeleteTLPropertyProcessor already deletes the associated FLEX_DATA rows when removing an attribute.
- DeletedObjectPurge cleans up Flex data and link rows for deleted objects at runtime; however, it operates on a running KnowledgeBase and is therefore only usable as a template for the logic, not directly in the migration.
Note on the association table
References may be stored not only in ` hasWrapperAttValue ` but also in other tables based on ` hasWrapperAttValueBaseAssociation ` (Unversioned, Bag, Historic variants, or application-specific tables). `delete-class ` and `delete-module` are not aware of where individual references are stored. Suggestion: Use MigrationContext#getPersistentRepository() to identify all tables in this hierarchy and delete them in each table using an IN set on META_ATTRIBUTE_ID or SOURCE.
Affected classes
- com.top_logic.element.model.migration.model.DeleteTLModuleProcessor
- com.top_logic.element.model.migration.model.DeleteTLClassProcessor
- com.top_logic.model.migration.Util#deleteTLType