[
https://issues.apache.org/jira/browse/ATLAS-1690?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15999062#comment-15999062
]
Suma Shivaprasad edited comment on ATLAS-1690 at 5/5/17 10:30 PM:
------------------------------------------------------------------
In response to [~davidrad] 's comment ,
3. Interesting idea. You are right - tag propagation is important. As these are
not bidirectional relationships, there is not an implied direction-it is not
obvious which way the propagation should flow. I could see us wanting to do
this sort of thing for composition (which are not modelled by a top level
relationship). I suspect it is less likely that for 2 independent entities we
would want to propagate tags using flags in the types.
Ideally propagation of tags should be defined in Ranger rules - as we are
likely to want different tag propagation in different contexts. Can I suggest
we deal with classification in a subsequent design? We can then cover Semantic
classification which will actually be a relationship.
--> Can you pls elaborate or point me to jira/design docs where tag propagation
has been detailed out?
4. Yes this is the same as Suma's suggestion of a category; I was thinking of
"bidirectional”, “aggregation” - as association could be directional and
contains could be composition . I will put this in, as we can then put this
value into the edge - so we can identify which edges we need to expand into
attributes. Are you OK with these amendments?
--> I think we should have four categories initially - composition,
aggregation, bidirectional, directional. Its important to distinguish between
aggregation and composition I think, since tag propagation and entity mutation
cascade policies like delete etc can be controlled based on this. Also
capturing bidirectional vs directional would help us in migrating the current
technical model where a unidirectional relation could just have ownedRef on one
side and there s no reverseAttribute on the referred end and the default could
be bidirectional associations.
was (Author: suma.shivaprasad):
In response to [~davidrad] 's comment ,
4. Yes this is the same as Suma's suggestion of a category; I was thinking of
"bidirectional”, “aggregation” - as association could be directional and
contains could be composition . I will put this in, as we can then put this
value into the edge - so we can identify which edges we need to expand into
attributes. Are you OK with these amendments?
--> I think we should have four categories initially - composition,
aggregation, bidirectional, directional. Its important to distinguish between
aggregation and composition I think, since tag propagation and entity mutation
cascade policies like delete etc can be controlled based on this. Also
capturing bidirectional vs directional would help us in migrating the current
technical model where a unidirectional relation could just have ownedRef on one
side and there s no reverseAttribute on the referred end and the default could
be bidirectional associations.
> Introduce top level relationships
> ---------------------------------
>
> Key: ATLAS-1690
> URL: https://issues.apache.org/jira/browse/ATLAS-1690
> Project: Atlas
> Issue Type: Improvement
> Reporter: David Radley
> Assignee: David Radley
> Labels: VirtualDataConnector
> Attachments: Atlas_RelationDef_Json_Structure_v1.pdf, Atlas
> Relationships proposal v1.0.pdf, Atlas Relationships proposal v1.1.pdf, Atlas
> Relationships proposal v1.2.pdf, Atlas Relationships proposal v1.3.pdf, Atlas
> Relationships proposal v1.4.pdf, Atlas Relationships proposal v1.5.pdf, Atlas
> Relationships proposal v1.6.pdf, Atlas Relationships proposal v1.7.pdf
>
>
> Introduce top level relationships including support for
> -many to many relationships
> - relationship names including the name for both ends and the relationship.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
