Relations / Remove unused table and use feature catalogue citation - #9442
Open
juanluisrp wants to merge 3 commits into
Open
Relations / Remove unused table and use feature catalogue citation#9442juanluisrp wants to merge 3 commits into
juanluisrp wants to merge 3 commits into
Conversation
juanluisrp
added
bug
db change
josegar74
approved these changes
Jul 21, 2026
josegar74
left a comment
josegar74
left a comment
Member
There was a problem hiding this comment.
@juanluisrp looks fine, added some small code improvements
josegar74
approved these changes
Jul 22, 2026
The Relations table was only written by MEF import (to record a metadata to feature catalogue link) and read back by the deprecated relations service and the legacy "related" type of the related records API. The feature catalogue association is already expressed in the metadata through the feature catalogue citation, which is what the rest of the catalogue relies on, so the table is redundant. Remove the MetadataRelation entity, its repository, specification, entity listener and the deprecated relations service, and add a migration to drop the table. MEF export now resolves the associated feature catalogue from the metadata citation (AssociatedResourcesSchemaPlugin) and writes the referenced feature catalogue record into the applschema folder, including it according to the current user's view privileges. When a record cites several feature catalogues the selection is deterministic. MEF import no longer writes a relation row; the imported feature catalogue instead inherits the categories and privileges of its parent record. The deprecated "related" type of the related records API now returns feature catalogues from the index only.
Small code improvements and cleanup
juanluisrp
force-pushed
the
relations-table-removal
branch
from
July 23, 2026 11:14
07c6361 to
b2b1997
Compare
The migration was dropping the Relations table now that the MetadataRelation entity and its repository are gone. The table was never kept in sync with metadata updates or deletes, so its content is of uncertain reliability, but dropping it outright leaves no way to recover anything from it during the upgrade window. Leave the table in the database, unmapped and unused by the application, so its historical data stays available if ever needed. Fresh installs never get the table at all, since it is no longer backed by an entity.
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.
Overview
The
Relationstable was only populated by MEF import (to record a metadata → feature catalogue link) and read back by the deprecated relations service and the legacyrelatedtype of the related records API. That association is already carried in the metadata itself through the feature catalogue citation, which is what the rest of the catalogue uses, so the table is redundant. This PR removes the entity and code around it, and derives the feature catalogue link from the citation instead.Changes
MetadataRelationentity, its repository, specification, entity listener, and the deprecatedservices/relationsservice (Get/Insert/Remove), plus their tests.v4413) that stops managing theRelationstable. The table is left in the database as-is, unmapped and unused by the application, so its historical data stays available if ever needed; fresh installs never get the table at all, since it is no longer backed by an entity.AssociatedResourcesSchemaPlugin.getAssociatedFeatureCatalogueUUIDs) and write the referenced feature catalogue record into theapplschema/folder, included according to the current user's view privileges. Previously the exporter wrote the main record intoapplschema/instead of the feature catalogue; that is now correct. Selection is deterministic when several feature catalogues are cited.relatedtype of the related records API now returns feature catalogues from the index (hasfeaturecats) only.Notes
applschema/folder convention) is unchanged.relatedresponse element is no longer emitted; the UI and formatters do not depend on it (they use the associated-resources /fcats/hasfeaturecatspaths).Relationstable is intentionally not dropped by the migration. It was never kept in sync with metadata updates or deletes, so its content is of uncertain reliability, but leaving it in place preserves the option to recover from it if needed.Testing
mvn clean install -DskipTestsbuilds cleanly.MEFLibIntegrationTest— covers MEF v2 import with a related feature catalogue inheriting categories and privileges.MEFExporterIntegrationTest.MetadataAssociatedApiTest— covers exporting a record whose cited feature catalogue is written intoapplschema/.