Hi Madhan, I have re-read your proposal again - this makes sense. I have further suggestion; I like the way of using an existing attribute as a display name; I wonder if we should have display name as a flag on AttributeDef, if there were multiples specified then we could concatinate or police to only allow one. This would allow people to create a new attribute called displayAttribute if they like or use an existing attribute like name in the GlossaryCategory case. It would also mean that classifications, relationships and structures could have display names.
I wonder if the displayName is not specified for Entities, then we could default it to the first unique attribute value if there are unique attributes, if not then we could default to the qualified name for Referenceables. If we wanted we could sample the data values and look for the most unique and use that! all the best, David. ----- Forwarded by David Radley/UK/IBM on 22/07/2017 22:02 ----- From: David Radley/UK/IBM To: [email protected] Cc: [email protected] Date: 22/07/2017 15:25 Subject: Re: Relationships diagnostics Hi Madhan, I agree with the improvements to the error messages. That will really help. Just so I am clear, are you saying in addition to the relationship attributes, that the displaytext would be defined as an attribute name in an end in the relationshipDef - or something else ? all the best, David. ----- Original message ----- From: Madhan Neethiraj <[email protected]> Sent by: Madhan Neethiraj <[email protected]> To: David Radley <[email protected]>, Madhan Neethiraj <[email protected]>, Sarath Subramanian <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Re: Relationships diagnostics Date: Fri, Jul 21, 2017 3:39 PM David, It will help if the error message can include the details like attribute name. Consider the following: > "invalid value for relationship attribute ‘terms’: entity specified (guid=000-111-222) could not be found" > "invalid entity-type for relationship attribute ‘terms’: entity specified (guid=000-111-222) is of type ‘Glossary’, but expected type is ‘GlossaryTerm’ " About adding displayText to relationshipAttributes – Sarath and I discussed yesterday to use AtlasRelatedObjectId objects for relationshipAttributes instead of AtlasObjectId. This type would include details like attributes of the relationship itself – along with displayText, etc . class AtlasRelatedObjectId extends AtlasObjectId { String relationGuid; AtlasStruct relationAttributes; String displayText; } Sarath should be creating a JIRA shortly. >> I suggest we add a displayname to each of the ends in the RelationshipDef Instead of adding ‘displayTextAttributeName’ attribute to RelationshipDef ends, we should add this to AtlasEntityDef – so that it can be used to populate AtlasEntityHeader.displayText, which is used in other places like search results. Currently AtlasEntityHeader.displayText field is set to either ‘name’ or ‘qualifiedName’ attribute value. Thanks, Madhan From: David Radley <[email protected]> Date: Friday, July 21, 2017 at 3:01 AM To: Madhan Neethiraj <[email protected]>, Sarath Subramanian <[email protected]> Cc: "[email protected]" <[email protected]> Subject: Relationships diagnostics Hi Madhan and Sarath, I am playing with relationships and the glossary models. When I make mistakes I am finding it difficult to work out what I have done wrong or whether there is a bug somewhere. I intend to improve the diagnostics. The error I get back from an incorrect relationship creation is not very descriptive: { "errorCode": "ATLAS-400-00-01A", "errorMessage": "invalid parameters: found null entity" } I will look into to add more specific error messages . Something like "guid 000-111-222 was specified on relationship 111-222-333 on end1 and could not be found" "guid 000-111-222 was specified on relationship 111-222-333 on end1 and was found, the expected type GlossaryTerm, but found type Glossary," I think it would help in the relationshipAttributes if we could include a displayname. So I suggest we add a displayname to each of the ends in the RelationshipDef. The contents would be an attributename in the type. For example the displayname of a GlossaryCategory. I think this will be really useful when there are no unique attributes - like for GlossaryTerm and GlossaryCategory. We would then see these names in the entity relationship attributes. When the glossary entity is displayed the associated categories entires would have meaningful (but not unique) names in addition to the guid and type. I will go ahead with the error messages - are there any objections to including a displayname on the relationship endpoints? all the best, David. Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU Unless stated otherwise above: IBM United Kingdom Limited - Registered in England and Wales with number 741598. Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU
