Links
A link is a directed edge between two objects that define a relationship. Cloud Directory currently supports the following link types.
Child Links
A child link creates a parent–child relationship between the objects it connects. For
example, in the above illustration child link b connects
objects 001
and 003
. Child links define the
hierarchy in Cloud Directory. Child links have names when they participate in defining the
path of the object that the link points to.
Attachment Links
An attachment link applies a leaf node policy object to another leaf node or a node
object. Attachment links do not define the hierarchical structure of Cloud Directory. For
example, in the above illustration, attachment link applies the policy stored in policy
leaf node object 006
on node object 002
. Each
object can have multiple policies attached but not more than one policy of any given
policy type can be attached.
Index Links
Index links provide rich information lookup based on an index object and your defined indexed attributes, thus enabling fast tree traversals and searches within the directory trees. Conceptually, indexes are similar to nodes with children: The links to the indexed nodes are labeled according to the indexed attributes, rather than being given a label when the child is attached. However, index links are not parent-child edges, and have their own set of enumeration API operations. For more information, see Indexing and Search.
Typed Links
Typed Links enable you to establish a relationship between objects within or across hierarchies in Cloud Directory. You can then use these relationships to query for information, such as Which users have device ‘xyz’ or What devices are owned by user ‘abc’.
You can use typed links to model relationships between different objects in your
directory. For example, in the illustration above, consider the relationship between
object 004
, which represents a user, and object
005
, which represents a device.
We might use a typed link to model an ownership relationship between the two objects. We could add attributes to the typed link to represent the cost of a purchase, whether the device is rented or purchased. There are two types of attributes associated with typed links:
-
Identity-based attributes – An attribute of a typed link that distinguishes it from other links (For example, Child, Attachment, Index links). Each typed link facet defines an ordered set of identity attributes. The identity of a typed link is the source object id, a facet identifier (type), the values of its identity attributes (defined by its facet), and the target object id. Identifiers must be unique within a single directory.
-
Optional attributes - An attribute that stores tracking characteristics about the typed link that are unrelated to the identity of the link. For example, an optional attribute might identify the date the typed link was first established or when it was last modified.
As with objects, you must create a typed link facet using the CreateTypedLinkFacet
API to define the typed link structure and
its attributes. Typed link facets require a unique facet name and set of attributes that
are associated with the link. When designing your typed link structure, you can define an
ordered set of attributes on the typed link facet. To view a typed links sample schema,
see Schema Document with Typed Links.
Typed link attributes can be used when you need to do any of the following:
-
Allow for filtering of incoming or outgoing typed links. For more information, see Typed Link Listing.
-
Represent the relationship between two objects.
-
Track administrative data about your typed link, such as the date the link was created.
Consider the following when deciding if typed links are right for your use case:
-
Typed links cannot be used in path-based object specification. Instead, you must select typed links using the
ListOutgoingTypedLinks
orListIncomingTypedLinks
API operations. -
Typed links do not participate in
LookupPolicy
orListObjectParentPaths
API operations. -
Typed links between the same two objects and in the same direction may not have the same attribute values. This can help avoid duplicated typed links between the same objects.
-
Additional attributes can be used when you want to add optional information.
-
The combined size of all identity attribute values is limited to 64 bytes. For more information, see Amazon Cloud Directory Limits.
Related Cloud Directory Blog Article
Typed Link Identity
Identity is what uniquely defines whether a typed link can exist between two
objects. The exception is when you connect two objects in one direction with the exact
same attribute values. Attributes must be configured as REQUIRED_ALWAYS
.
Typed links that are created from different typed link facets never conflict with each other. For example, consider the following diagram:
-
Object
001
has typed links and attributes (A1 and A2) with the same attribute values (x1 and x2) going to different objects (002
and003
). This operation would succeed. -
Objects
002
and003
have a typed link between them. This operation would fail because two typed links in the same direction with the same attributes cannot exist between objects. -
Objects
001
and003
have two typed links between them with the same attributes. However, since the links go in different directions, this operation would succeed. -
Objects
002
and003
have typed links between them with the same value for A1 but different values for A2. Typed link identity considers all attributes so this operation would succeed.
Typed Link Rules
You can add rules to typed link attributes when you want to add restrictions to link attributes. These rules are equivalent to rules on object attributes. For more information, see Attribute Rules.
Typed Link Listing
Cloud Directory provides API operations that you can use to select incoming or outgoing typed links from an object. You can select a specific subset of typed links rather than iterating over every typed link. You can also specify a particular typed link facet to filter only typed links of that type.
You can filter typed links based on the order that the attributes are defined on the typed link facet. You can provide range filters for multiple attributes. When providing ranges to a typed link selection, any inexact ranges much be specified at the end. Any attributes with no range specified are presumed to match the entire range. Filters are interpreted in the order of the attributes that are defined on the typed link facet, not the order they are supplied to any API calls.
For example, in the following diagram, consider a Cloud Directory that is used to store information about Employees and their Abilities.
Let’s say we model our employee’s capabilities with a typed link named
EmployeeCapability
, which is configured with three string attributes:
Status
, Role
and Created
. The following filters
are supported on ListIncomingTypedLinks
and ListOutgoingTypedLinks
API operations.
-
Facet =
EmployeeCapability
, Status =Active
, Role =Driver
-
Selects active employees who are drivers. This filter includes two exact matches.
-
-
Facet =
EmployeeCapability
, Status =Active
, Role =Driver
, Created =05/31/18
-
Selects active employees who are drivers and who's facets were created on or after May 31st, 2018.
-
-
Facet =
EmployeeCapability
, Status =Active
-
Selects all active employees.
-
-
Facet =
EmployeeCapability
, Status =Active
, Role =A
toM
-
Selects active employees with roles starting with
A
throughM
.
-
-
Facet =
EmployeeCapability
-
This selects all typed links of the
EmployeeCapability
type.
-
The following filters would NOT be supported:
-
Facet =
EmployeeCapability
, Status betweenA
toC
, Role =Driver
-
This filter is not allowed because any ranges must appear at the end of the filter.
-
-
Facet =
EmployeeCapability
, Role =Driver
-
This filter is not allowed because the implicit status range is not an exact match and does not appear at the end of the list of ranges.
-
-
Status =
Active
-
This filter is not allowed because the typed link facet is not specified.
-
Typed Link Schema
You can create typed link facets in two ways. You can manage your typed link facets
from individual API calls, including CreateTypedLinkFacet
, DeleteTypedLinkFacet
, and UpdateTypedLinkFacet
. You can also upload a JSON document that
represents your schema in a single PutSchemaFromJson
API call. For more information, see JSON Schema Format. To view a typed links sample schema, see Schema Document with Typed Links.
The types of changes allowed at different phases of the schema development lifecycle are similar to changes that are allowed for object facet manipulation. Schemas in the development state support any changes. Schemas in the published state are immutable and no changes are supported. Only certain changes are allowed to schemas that are applied to a data directory. Once you set the order and attributes on an applied typed link facet, that order cannot be changed.
Two other API operations list facets and their attributes:
Typed Link Interaction
Once a typed link facet has been created, you are ready to start creating and
interacting with typed links. To attach and detach typed links, use the AttachTypedLink
and DetachTypedLink
API operations.
The TypedLinkSpecifier
is a structure that contains all the information
to uniquely identify a typed link. Within that structure you can find
TypedLinkFacet
, SourceObjectID
,
DestinationObjectID
, and IdentityAttributeValues
. These are
used to uniquely specify the typed link being operated on. The AttachTypedLink
API operation returns a typed link specifier
while the DetachTypedLink
API operation accepts one as input. Similarly,
the ListIncomingTypedLinks
and ListOutgoingTypedLinks
API operations provide typed link
specifiers as output. You can construct a typed link specifier from scratch as well. The
full list of typed link-related API operations, include the following:
Note
Attribute references and updating typed links are not supported. To update a typed link, you must remove it and add the updated version.