enhancement
major
minor
defect
critical
major
minor
major
#30184
DeleteTableProcessor does not remove " <alternative>" elements from the stored schema
Problem
The DeleteTableProcessor (tag <delete-table>, package com.top_logic.knowledge.service.migration) removes tables from the stored database schema, but deletes only the <metaobject> and <association> elements (XPath //metaobject[...] | //association[...]). An <alternative> that lists the deleted table as a <specialization> remains in the saved schema and subsequently refers to a table that no longer exists.
Consequence
The application fails to start in MigrationService while building the type system:
UnknownTypeException: Unknown table 'Item', available tables are: ... at MOAlternativeImpl.resolve at DefaultMORepository.resolveReferences at MigrationService.createKB / MigrationContext.<init>
The message does not specify either the alternative or the migration that caused the problem.
Example
The schema declares:
<alternative object_name="FolderContent">
<specialization name="Folder"/>
<specialization name="Item"/>
</alternative>
A migration deletes the Folder and Item tables using <delete-table>. Afterward, the saved schema still contains the FolderContent alternative.
Second Problem
Abstract objects without a physical table cannot be removed using <delete-table>: The processor executes DROP TABLE for every object it finds, and this fails if no table exists. The object remains in the stored schema, and the engine re-declares it in autoconf/inapp-schema-*.meta.xml at startup.
Expected Behavior
- <delete-table> also removes <alternative> elements from the stored schema that now contain only deleted tables, and removes deleted tables from the <specialization> elements of the remaining alternatives.
- For abstract objects without a table, no DROP TABLE is executed (or there is a way to remove them from the schema).
- If a reference to a deleted table still remains, the error message specifies the alternative.
Workaround
Instead of <delete-table>, use the RemoveApplicationTypesProcessor and list not only the tables but also the abstract objects and the affected alternatives as <application-table> within it:
{{{#!xml <processor class="com.top_logic.knowledge.service.migration.processors.RemoveApplicationTypesProcessor">
<application-tables>
<application-table name="Folder" db-name="FOLDER"/>
<application-table name="Item" db-name="ITEM"/>
<application-table name="FolderContent" db-name="FOLDER_CONTENT"/>
</application-tables>
</processor> }}}
- The processor removes all specified entries (including <alternative>) from the stored schema.
- If a table (abstract object, alternative) is missing, deletion results only in a warning, not an error. db-name is required; any name is sufficient for these entries.
- If an alternative remains that lists a deleted table alongside other tables, the <specialization> must also be removed from the stored schema using the XsltTableDefinitionBaselineProcessor (as a pre-processor), see Ticket_29019_Removed_log_entries.migration.xml.
Alternatively: Do not delete tables that appear in an <alternative> and retain their declarations.