major
nice-to-have
defect
major
The TLClass tag should be extended to include a reference to the tagged object. This was previously requested in #21498. However, the original issue was ultimately resolved differently:
This ticket was implemented to use these tags in version comparisons in #21402. However, this was later changed so that revisions are used directly.
Therefore, the ticket was closed. However, this is now also used for Kafka schema management in Codim. And there is also a similar attribute in POS. Therefore, this attribute should be included directly in the base code.
Situation in POS
- The file Tag.model.xml has been overwritten. (Meaning: Copied to POS under the same name.)
- Two additional types are defined:
- Tag.projectArchive
- ProjectArchiveTag
- Tag.projectArchive extends Tag.all by adding the taggedObj attribute as well as half a dozen other domain-specific attributes.
- taggedObj is defined as:
{{{#!xml <reference name="taggedObj" kind="forwards" mandatory="true" type="tl.tables:ObjectTableInterface" > <annotations> <delete-protected/> <storage-algorithm> <historic-storage/> </storage-algorithm> </annotations> </reference> }}}
Situation in Codim
- The Tag.model.xml file in the base system has been extended with the Tag.all#businessObject attribute:
{{{#!xml <reference name="businessObject" kind="forwards" type="tl.tables:ObjectTableInterface" > <annotations> <delete-protected/> <storage-algorithm> <historic-storage/> </storage-algorithm> </annotations> </reference> }}}
Proposed Implementation
- For the sake of POS, the attribute should be named `taggedObj `. This saves POS from having to perform a migration. The migration in Kafka schema management is likely to be much simpler, since the entire project is much smaller.
- The attribute should not be mandatory so that a tag can be created even when one does not want to tag a specific object, but rather an entire data set.
- In all other respects, the two variants are identical. Therefore, the attribute should be defined exactly the same way in the base schema.
Data Migration
There is no automatic migration for this ticket, as it was decided during the Daily Scrum that there is currently no need for one, and that there are more important themes and not enough time.
Projects that do not depend on com.top_logic.project.pos must perform the following migration:
- The meta-attribute ` Tag:Tag.all#taggedObj ` has been introduced.
- See: [ A MetaAttribute]
- The KO attribute ` Tag#taggedObj ` has been introduced.
- See: [About a KO attribute]
Projects that depend on com.top_logic.project.pos must also perform the following migration:
- After consultation with POS, the TLModel attribute `Tag:Tag.projectArchive#taggedObj ` was moved to the ` Tag.all ` class so that it matches the definition in the base class.
- See: a meta-attribute]
- Furthermore, the attribute has been made non-mandatory.
- The MO reference `taggedObj` is now inherited from the `Tag ` MOClass. Previously, this reference was mapped in ` ProjectTagMeta.xml ` using the following four MO attributes: `taggedObj_BRC`, `taggedObj_REV`, `taggedObj_ID`, and `taggedObj_TYPE`. Instead, only the inherited MO reference remains. This does not change the database table definition. However, since the definition of the MetaObject is stored in the database itself, it must be updated accordingly there.
Ticket #23639 was created as part of this issue. It is a remnant of the attempt to create an automatic data migration for this purpose.
Test
No test, since the ticket needs to be completed, and a test would require, for example, new features to be added to the demo to demonstrate and test object tagging.