Feature
The glossary term relations API (POST/DELETE /v1/glossaryTerms/{id}/relations, GET .../relationsGraph, GET .../relationTypes/usage) and the glossaryTermRelationSettings system setting are not wrapped by either 2.0 SDK. Callers must drop to the raw HTTP escape hatch (client().ometa.client in Python, getHttpClient().execute(...) in Java), so every caller re-implements FQN→id resolution, the TermRelation payload shape, and the JSON-Patch construction for registering relation types.
This tracks making that surface first-class in both the Python (metadata.sdk) and Java (openmetadata-sdk) 2.0 SDKs.
Motivation
Creating typed glossary relationships at scale (e.g. ontology / RDF import, bulk prescribes / prescribedBy edges) currently requires hand-rolled REST calls. A first-class SDK removes the boilerplate and makes the clobber-safe relation-type registration pattern the default.
Proposed API
Python (from metadata.sdk import GlossaryTerms, Settings)
GlossaryTerms.add_relation(from, to, relation_type)
GlossaryTerms.remove_relation(from, to, relation_type=None)
GlossaryTerms.relations_graph(term, depth=, relation_types=)
GlossaryTerms.relation_type_usage()
- new
Settings facade: define_glossary_relation_type(...) (idempotent), glossary_relation_types()
Java
GlossaryTermService.addRelation / removeRelation / relationGraph / relationTypeUsage
- new
SystemSettingsService exposed as client.settings() with defineGlossaryRelationType (idempotent)
- fluent
GlossaryTerms.find(id).relateTo(to).as(type).apply()
Acceptance criteria
Implementation
Implemented by #29788.
Feature
The glossary term relations API (
POST/DELETE /v1/glossaryTerms/{id}/relations,GET .../relationsGraph,GET .../relationTypes/usage) and theglossaryTermRelationSettingssystem setting are not wrapped by either 2.0 SDK. Callers must drop to the raw HTTP escape hatch (client().ometa.clientin Python,getHttpClient().execute(...)in Java), so every caller re-implements FQN→id resolution, theTermRelationpayload shape, and the JSON-Patch construction for registering relation types.This tracks making that surface first-class in both the Python (
metadata.sdk) and Java (openmetadata-sdk) 2.0 SDKs.Motivation
Creating typed glossary relationships at scale (e.g. ontology / RDF import, bulk
prescribes/prescribedByedges) currently requires hand-rolled REST calls. A first-class SDK removes the boilerplate and makes the clobber-safe relation-type registration pattern the default.Proposed API
Python (
from metadata.sdk import GlossaryTerms, Settings)GlossaryTerms.add_relation(from, to, relation_type)GlossaryTerms.remove_relation(from, to, relation_type=None)GlossaryTerms.relations_graph(term, depth=, relation_types=)GlossaryTerms.relation_type_usage()Settingsfacade:define_glossary_relation_type(...)(idempotent),glossary_relation_types()Java
GlossaryTermService.addRelation/removeRelation/relationGraph/relationTypeUsageSystemSettingsServiceexposed asclient.settings()withdefineGlossaryRelationType(idempotent)GlossaryTerms.find(id).relateTo(to).as(type).apply()Acceptance criteria
GlossaryTerms+ aSettingsfacade, exported frommetadata.sdkSystemSettingsServicewired intoOpenMetadataClient/relationTypes/-, not GET→append→PUT) and idempotentGlossaryTermRelationsITuses the SDK instead of rawjava.net.httpImplementation
Implemented by #29788.