https://datahubproject.io logo
Join Slack
Powered by
Hello everybody, We're currently having troubles w...
# advice-metadata-modeling
g
Hello everybody, We're currently having troubles with correctly making newly added aspects for GlossaryTerm visible. We went the fork route (at least for now - most changes might be probably moved to the custom extensions later), added "autoRender": true (trying both "tabular" and "properties" values for "displayType"), but the new aspect is not displayed. We tried adding a default value (just in case that having some value is required for the aspect to be displayed), but no avail so far. Any ideas? As of now, we experiment with the simplest possible version - the new aspect contains just one string attribute (we want to play with other types later, but I understand there may be additional gotchas for those).
e
Hey @gentle-portugal-21014 this is on the frontend you’re experiencing an issue?
g
Hi @echoing-airport-49548, yes, I expect to see the added aspect / attribute displayed (and made editable) on the front-end, but that's not happening... We don't see the new attribute/aspect in the ElasticSearch documents for newly created glossary terms either despite the default value specified in the aspect, but that's not important per se as long as the attribute/aspect is displayed on the front-end.
e
Got it did you make sure that the new attribute is mapped in the GraphQL resolver so it’s returned when we fetch glossary terms on the frontend?
g
Based on the description in the docs, it seemed to me that adding the aspect with "autoRender": true should be sufficient for getting it in the front-end. Am I wrong and it needs to be added somewhere else (where exactly?), or do you just ask whether the new aspect appeared in the results of the GraphQL query for GlossaryTerm?
@echoing-airport-49548: I'm still not clear whether you meant that I should make sure to update the "GraphQL resolver" somewhere in the sources (where), or whether you wanted me to check the result of the GraphQL query. However - I tried to check a GraphQL query using /api/graphiql and I don't seem to be able to access the new aspect there - I can query a particular glossaryTerm using:
Copy code
{
  glossaryTerm(urn: "urn:li:glossaryTerm:...") {
      glossaryTermInfo
  }
}
This expands "glossaryTermInfo" with the respective fields, but those do not directly match the definition of the glossaryTermInfo aspect (as an example, GlossaryTermInfo.pdl contains an attribute called "definition", but GraphiQL knows this attribute as "description"). And to get back to your question - no, name of our newly added aspect is not recognized in GraphiQL (and I don't know how to change). On the other hand, I can populate the newly added aspect using "datahub put" from the CLI (and I'm pretty sure it would work using the respective REST call as well, because that's what the CLI uses internally as well) - which means that the aspect is generated properly from the build and deployment point of view, because "datahub put" rejects attempts to populate unknown aspects and/or attributes not matching the aspect definition... Any help is more than welcome...
e
g
Alright, many thanks, we'll try that.
OK, @echoing-airport-49548. What we did so far: 1. We extended entity.graphql as suggested above with attributes defined in the new aspect - is that what you meant? 2. We added mapping for the new attributes into GlossaryTermMapper.java. 3. We also found that we probably need to extend https://github.com/datahub-project/datahub/blob/master/datahub-graphql-core/src/ma[…]m/linkedin/datahub/graphql/types/glossary/GlossaryTermType.java, in particular ASPECTS_TO_RESOLVE. 4. CreateGlossaryTermResolver.java probably needs to be extended in order to allow editing the new aspects in UI, right? This makes the attributes available for the GraphQL queries, but still nothing for the UI. 😞 In addition, we found some possible other places which seemed to be related to getting the attributes to the UI, in particular https://github.com/datahub-project/datahub/blob/master/datahub-web-react/src/graphql/fragments.graphql, https://github.com/datahub-project/datahub/blob/master/datahub-web-react/src/graphql/glossaryTerm.graphql, but trying to extend those didn't help either. Do we need to extend something in https://github.com/datahub-project/datahub/tree/master/datahub-web-react/src/app/glossary, https://github.com/datahub-project/datahub/tree/master/datahub-web-react/src/app/entity/glossaryTerm and/or https://github.com/datahub-project/datahub/tree/master/datahub-web-react/src/app/entity/shared/containers/profile/sidebar?
e
Okay those are all great steps! Yes you need to get the attributes in the UI in 
glossaryTerm.graphql
If it’s working properly, in the network request tab on Chrome if you filter for 
graphql
, you should see the GraphQL API calls and see which fields are being returned
You would still need to render those fields in the UI
Where exactly do you want them to show up?
If you can send me a screenshot that’d be great
g
Thanks again for your great support! Let's say that the documentation of the meaning of autoRender attribute in the .pdl files is somewhat misleading 😉 (does this attribute do anything useful at all?), but that's not the most important point. As far as the location for the new attributes is concerned - we'd probably want to show a "subType" attribute (or something similar if "subType" already exists for GlossaryTerm) somewhere in the area where the "name" is displayed, and then display additional attributes in the sidebar (possibly a new section below "About"?) conditionally depending on the value of the "subType" attribute; if I understand it correctly, the subType concept is used similarly for the Dataset entity (to display additional attributes for subType = VIEW).
e
I’m not super familiar with the 
autoRender
attribute but @big-carpet-38439 can speak more to that
So to clarify, this would be on a glossary entity right?
g
Yes, that's our current focus. We'll need to extend the Dataset entity little bit as well afterwards, but let's finish the Glossary Term part first.
@big-carpet-38439 - could you please clarify the supposed effect of setting autoRender attribute in the PDL files, since it clearly doesn't result in displaying the added aspect in the GUI automatically (unlike what we expected after reading the related part of documentation about metamodel extensions)?
g
Hey there @gentle-portugal-21014 - auto render was an experimental feature built specifically for datasets, we did not extend it to other entity types
that’s why you aren’t seeing it on the glossary term page
g
Hello @green-football-43791, thanks, good to know, we'll try how it works for our extensions needed for datasets. :-)
Hi @green-football-43791, I tested it a bit and I'm facing some strange things: 1. A simple aspect containing just a single string attribute with displayType:properties displays correctly. 2. Equally simple aspect defined with displayType:tabular and "key" set to the name of the included string attribute results in a completely empty page after clicking on the link with the corresponding displayName. I mean really completely empty (white) page in the browser, not just no content in that tab. Why? 3. A little bit more complex aspect containing 4 attributes (one of them being an enum, another being boolean) and displayType:properties is not displayed at all (i.e. the defined displayName is not shown as a new tab). Is automated rendering limited to aspects containing just string attributes? Or what else might be the reason of this behaviour?
A follow-up to the last point - any aspect containing more than one attribute (even if all of them are of type string) is not displayed apparently. :-(
2 Views
Open in Slack
PreviousNext
Powered by