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
