enhancement
major
minor
defect
critical
major
minor
When alter-column targets a table that is abstract (e.g. epp.plan.SimpleObject), the processor correctly alters the DB columns on all concrete subtypes via adjustTable(), but fails to update the stored schema for the abstract type.
**Root cause:** In AlterColumnProcessor.doMigration(), abstract types are skipped in the loop (line 154). The list tablesWithDeclaredAttribute only collects concrete types where hasDeclaredAttribute() is true (line 170). If a column is declared on an abstract type and all concrete subtypes only inherit it, tablesWithDeclaredAttribute is empty and adjustStoredSchema() updates nothing.
**Impact:** Subsequent processors that read context.getPersistentRepository() (e.g. RecollateStringColumnsProcessor) still see the old column type from the stored schema. In our case, this caused the TL8 migration to fail because RecollateStringColumnsProcessor generated ALTER COLUMN TYPE VARCHAR(4000) COLLATE "tl_ci" instead of ALTER COLUMN TYPE TEXT COLLATE "tl_ci" for CLOB columns, failing on data exceeding 4000 characters.
**Suggested fix:** After the for-loop in doMigration() (after line 173), add the specified table to tablesWithDeclaredAttribute if it declares the column but was not processed (because it is abstract):
// Include the specified table if it declares the column but was not processed
// (e.g., because it is abstract and was skipped in the loop above).
if (!tablesWithDeclaredAttribute.contains(tableName)
&& abstractTable.hasDeclaredAttribute(columnName)) {
tablesWithDeclaredAttribute.add(tableName);
}
**File:** com.top_logic/src/main/java/com/top_logic/knowledge/service/db2/migration/AlterColumnProcessor.java
**Workaround:** A separate MigrationProcessor that loads the persistent schema, sets the correct DBType on the abstract type's column, and stores it back via AddMOAttributeProcessor.updateStoredSchema().