Hi Shwetha,
OK Thanks - what is your thinking around possible changes to
EntityResourceDefinition?
all the best, avid.
From:
To: "dev@atlas.incubator.apache.org" <dev@atlas.incubator.apache.org>
Date: 20/09/2016 06:05
Subject: Re: Thoughts on the first step to understand the Atlas
data model internals
David,
EntityResourceDefinition was added as part of business catalog, and this
might change.
org.apache.atlas.web.resources.EntityResource and
org.apache.atlas.web.resources.TypesResource are the initial APIs added,
these are used by AtlasClient and Atlas UI and is also documented in
Hemanth¹s doc
Regards,
Shwetha
On 15/09/16, 8:27 PM, "David Radley" <david_rad...@uk.ibm.com> wrote:
>Hi Hermanth,
>Thanks for your response. I agree we should evolve the existing
>documentation. I was aware of the guide you pointed me to. This appears
>to
>be useful for a user of the REST API. This sort of document is sometimes
>known as an application programming guide. The motivation of this persona
>is to effectively use the Atlas REST APIs to manage their metadata.
>
>I am interested in documenting the internal data model and motivation for
>the separations of concerns in the source code. This is for different
>personas, namely to document design consensus around the data model by
>and
>for the Atlas contributers and committers.
> all the best David.
>
>
>
>From: Hemanth Yamijala <hyamij...@hortonworks.com>
>To: "dev@atlas.incubator.apache.org" <dev@atlas.incubator.apache.org>
>Date: 15/09/2016 14:28
>Subject: Re: Thoughts on the first step to understand the Atlas
>data model internals
>
>
>
>David,
>
>This might not directly address all the points you mention below, but
>regarding learning about Atlas from a core understanding perspective, you
>may want to go through the document here:
>http://atlas.incubator.apache.org/AtlasTechnicalUserGuide.pdf. This is
>something we created just after the 0.7 release timeframe and feel it
>represents core concepts to a reasonable extent.
>
>There are several improvements that it needs:
>Likely, it is not complete and missing pieces.
>Further, being in PDF form makes it hard to edit, so moving it to a more
>editable format and specifically adding it to source code itself should
>be
>a goal.
>
>Etc...
>
>But if it forms a starting point, then it would be great to base further
>improvements on top of it.
>
>Thanks
>Hemanth
>________________________________________
>From: David Radley <david_rad...@uk.ibm.com>
>Sent: Thursday, September 15, 2016 6:26 PM
>To: atlas
>Subject: Thoughts on the first step to understand the Atlas data model
>internals
>
>Hi,
>I am looking to understand the important pieces in the Atlas architecture
>and the order that is useful to think about them. I wanted to check my
>understanding and questions around the top level data model concept as
>someone relatively new to the project. then update the docs. I am
>interested in feedback / thoughts / things I may have misunderstood. I
>think the next areas for a person looking to understand the internals to
>understand is the type system and providers and maybe then tracking how
>the code flows from the web to the graph.
>
>It seems that the data model of Atlas is the where to start; the
>fundamental interface is interface ResourceDefinition and the base object
>is BaseResourceDefinition. As the top level data object, I think this
>needs to be simple and intuitive and have a defined purpose.
>I would expect top level metadata objects should have the ability to have
>relationships and attributes, which it seems to have and a way to
identify
>them (names and guid - which I do not see in this object)
>
>I do not think the validate*** request call methods should live in this
>interface. I would separate out request logic from the core data model
>object; as they are different concerns.
>
>The baseResourceDefinition has :
> protected static final TypeSystem typeSystem =
TypeSystem.getInstance
>();
>
> protected final Set<String> instanceProperties = new HashSet<>();
> protected final Set<String> collectionProperties = new HashSet<>();
> protected Map<String, AttributeDefinition> propertyDefs = new
>HashMap<>();
> protected Map<String, AttributeInfo> properties = new HashMap<>();
>
> protected final Map<String, Projection> projections = new
HashMap<>();
> protected final Map<String, Relation> relations = new HashMap<>();
>
> protected final PropertyMapper propertyMapper;
> protected final Map<String, PropertyValueFormatter>
>propertyValueFormatters = new HashMap<>();
>
>
>There is an implied concept of Property here in the naming of these
>fields. If this is important then I suggest we have a Property class /
>Interface defining what we mean by it.
>I see there are projections and relationships. do we need both of these
>concepts in the top level object as the only implementation of a
>Projection is a RelationshipProjection.
>I see AttributeDefintion in the list, this class does not subclass
>ResourceDefintion - I am left thinking that in some way these are both
>Definitions which I would expect to be a super class / interface. Also
>given that this is in a systemtypes package it should be a system type.
>I see AttributeInfo and a not sure how this related to
>AttributeDefintions. It would be great to be able to add in javadoc to
>help here.
>EntityResourceDefinition implements ResourceDefinition but says typename
>is not meaningful for it. This is confusing. We should have an interface
>without a gettypename to be clean or at least an explanation.
>In UML, we often view relationships to other objects as attributes. I
>wonder how we think of attributes and relationships here - can you define
>an attribute with typeA and have a relationship to TypeA. Can I assume
>that attributes are contained compositions with the same lifeycle as the
>container. Relationships could be bidirectional ,directional or
>aggregation containment relationships with an independent lifecycle to
>the resourcedfintion
>PropertyValueFormatter I wonder why these are in the top level object. Do
>we expect different formatters for a given type? What is the use case
here
>- I wonder if we are exposing a plug point, so that other code could
>provide custom formatters. If this is the intent how would this work?
>PropertyMapper I find this name misleading. It seems to be translating
for
>fully formatted name to a clean name. I suggest using a more descriptive
>name like PropertyNameCleanser. Do we expect different Mappers for a
>given type? What is the use case here - I wonder if we are exposing a
plug
>point, so that other code could provide custom mappers. If this is the
>intent how would this work?
>
>I notice in the interface is has String getIdPropertyName(); This
>defaults to "id". This is confusing, from the above properties are
>attributes in the context of a ResourceDefinition. This seems to be
>referring to the hard coded id property in the Request REST object.
>
>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
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
