Is there a way to add properties to a Glossary Ter...
# advice-data-governanceb
brainy-table-99728
12/13/2022, 6:05 PMIs there a way to add properties to a Glossary Term via the UI or only via yaml file?
✅ 1
a
astonishing-answer-96712
12/13/2022, 6:07 PMNo, unfortunately you can only add properties through ingestion- either a yaml file or properties on the source
b
brainy-table-99728
12/13/2022, 6:07 PMthankyou1
a
adamant-furniture-37835
12/14/2022, 3:22 PMHi @astonishing-answer-96712, Is there a future plan to add this feature i.e. adding properties via UI ? Would you recommend to customize the UI to add a buttton "ADD" and utilize graphql apis to insert them to entities ?
a
astonishing-answer-96712
12/14/2022, 6:25 PMHi @adamant-furniture-37835, you can follow the feature request here! https://feature-requests.datahubproject.io/p/ability-to-add-edit-key-value-properties-for-glossary-terms-via-the-ui
g
gentle-portugal-21014
12/16/2022, 11:48 AMThe original question here is not specific as to whether it should be custom properties, or any additional attributes added to the PDL files as new aspects. We intended to use custom properties at first (and contribute this back, because we believe that it's of general interest as suggested by the feature request mentioned above). However, after trying to get some guidance from the project team (see the thread here), we're not so sure about usefullness of this approach with the limitations outlined by Chris Collins there. My attempt to sort out the discovered obstacles for the original approach using the suggested follow-up in the advice-metadata-modelling channel hasn't attracted too much attention so far - see here.
Going the other route of new aspects and adding support for them in the UI requires a lot of manual work (as discussed here) at the moment with the current status of PDL support and is far from anything general and/or useful for contributing back. A more general solution would be possible for sure (generation of GraphQL artifacts, Java classes and React code from the PDL files similarly to the existing great support for adoption of PDL defined structures in the REST API layer and ingestion), but it's a rather huge amount of work touching many parts of DataHub and implementing it would take too long for our needs.
a
astonishing-answer-96712
12/16/2022, 5:04 PMHi @gentle-portugal-21014, I’m sorry this has been giving you trouble. Just so I understand- you want the feature developed in a specific way, but it’s too far-reaching to be a feasible community contribution from your side? Is there any way you could capture this into a separate feature request so we’re aware these are two different features?
g
gentle-portugal-21014
12/19/2022, 4:58 PMHi @astonishing-answer-96712, no need to be sorry, it's open-source after all. 🙂
To make our use-case clear:
• We need to be able to add/edit additional attributes from UI.
• These attributes are not only strings, but also other types (boolean, enum).
• Allowing users to edit these other types as strings would be possible from technical point of view, but in reality unusable, because we'd immediately get various unexpected values due to typos, users not remembering the expected values, etc.
Potential solutions:
1. Use CustomProperties (existing feature available in the back-end) and add support for editing them in the UI (available in the front-end for e.g. DataSets with some limitations, but not at all for GlossaryTerms). To make this usable (see the third bulletpoint above), we'd need to be able to define a list of expected attributes (as of now, any attribute name is allowed for a new Custom Property) and their data types. I asked where to place such a list, but the received response suggested that this approach might not be supported within the project team and my attempt to discuss this further didn't lead anywhere so far.
2. Define new attributes using one or more new Aspects. Although this solution is documented as being feasible as an extension / "plugin" without messing with the product sources, this "extension" is only supported in the back-end at the moment (i.e. it allows using new attributes in ingestion and in the REST API), but not in the UI, and making the new attributes available in the UI requires very extensive modifications of the product sources, plus the changes need to be performed specifically for each and every individual attribute. Considering that some of these files which need to be modified contain comments like "Maps Pegasus {@link RecordTemplate} objects to objects conforming to the GQL schema. To be replaced by auto-generated mappers implementations", I assume that the current limitation of this solution is actually well known and intended to be removed later. Obviously, I can create a feature request so that this intention isn't forgotten.
Is my description clear now?
e
echoing-airport-49548
12/20/2022, 5:28 PMHey @gentle-portugal-21014 I’m wondering if we should set up a call to discuss this, since your use case is quite comprehensive and there’s a lot here
echoing-airport-49548
12/20/2022, 5:28 PMWould you be open to that?
g
gentle-portugal-21014
12/20/2022, 9:43 PMHi @echoing-airport-49548, sure, thanks, discussing it directly would be useful. We just need to pick a reasonable timeslot because you're probably 9 hours off my timezone if I understand it correctly (and my schedule outside of regular office hours is quite full before Christmas which complicates it little bit). As far as I'm concerned, we could have the call tomorrow at something like 22:30 CET (13:30 PST), or Thursday after 22:00 CET (13:00 PST). I'm afraid that a morning timeslot your time wouldn't be feasible for me before Christmas (but it would be an option for me e.g. on December the 27th or 28th).
e
echoing-airport-49548
12/20/2022, 10:01 PMI could do 13:30 PST Wednesday!
echoing-airport-49548
12/20/2022, 10:01 PMI’ll be on vacation starting Thursday until the New Year so that’s probably the best time
g
gentle-portugal-21014
12/20/2022, 11:15 PMAlright, thanks. 🙂 I don't know which communication platform you prefer - shall I setup something in MS Teams and provide the link here, or would you setup something in your preferred platform and give me the link?
e
echoing-airport-49548
12/20/2022, 11:16 PMWe can do a Zoom call, I can send you a calendar invite if you can DM me your email
g
gentle-portugal-21014
12/20/2022, 11:30 PMYou should have the DM now. :-)
gentle-portugal-21014
12/21/2022, 3:26 PM@echoing-airport-49548 Looking forward to our call. 🙂
In the meantime, I'll describe another issue we came across while working on this so that you could possibly have a look at this description in advance:
We need to add the new aspect and a value of an included attribute during creation of a new glossary term. We have tried to look on the datahub-web-react code and it seems that we should enhance current data type CreateGlossaryEntityInput in class glossaryTerm.graphql (datahub-web-react/src/graphql):
mutation createGlossaryTerm($input: CreateGlossaryEntityInput!) {
createGlossaryTerm(input: $input)
}
However, we have not found definition of this CreateGlossaryEntityInput type - it exists just in two classes:
1. CreateGlossaryEntityInput (com.linkedin.datahub.graphql.generated)
2. combined.graphql (docs-website/graphql)
which are both generated.
So our question is - is the data type CreateGlossaryEntityInput the right one to focus on and how to enhance its elements?
Second part is regarding the backend - GMS. While we were unlucky with modification of CreateGlossaryEntityInput on the frontend, we tried adding the new aspect in class CreateGlossaryTermResolver (com.linkedin.datahub.graphql.resolvers.glossary):
We have modified the class but it seems that the proposal can accommodate just one aspect at the time and adding more aspects destroys the original glossary term info information (like term name etc.).
Copy code
final MetadataChangeProposal proposal = new MetadataChangeProposal();
proposal.setEntityKeyAspect(GenericRecordUtils.serializeAspect(key));
proposal.setEntityType(Constants.GLOSSARY_TERM_ENTITY_NAME);
proposal.setAspectName(Constants.GLOSSARY_TERM_INFO_ASPECT_NAME);
proposal.setAspect(GenericRecordUtils.serializeAspect(mapGlossaryTermInfo(input)));proposal.setAspectName("glossaryTermTacr");proposal.setAspect(GenericRecordUtils.serializeAspect(mapGlossaryTermTacr(input))); Copy code
private GlossaryTermTacr mapGlossaryTermTacr(final CreateGlossaryEntityInput input) {
final GlossaryTermTacr result = new GlossaryTermTacr();
result.setJeEntita(false);
return result;
}22 Views