[
https://issues.apache.org/jira/browse/ATLAS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15172921#comment-15172921
]
David Kantor commented on ATLAS-535:
------------------------------------
I prefer option 3, as it provides a mechanism for modeling behavior that can
have use cases other than delete rules. For example, when exporting metadata
from Atlas, there can be closure rules applied to attributes which determine
which referenced objects are included in the export closure for a given type.
When importing metadata into Atlas, there can be merge rules applied to
attributes, which control how the data being imported is merged with existing
data. I understand that option 2 is easier to implement but my experience is
that it is worth doing the "right" thing as early as possible - it always seems
that once a mechanism is in place, it becomes harder to justify changing it as
other priorities emerge and there never seems to be a good time to do the
migration.
I think association rules should be defined on attributes, not on classes.
Modelers may define multiple references between two different classes (we saw
this many times), and there should be a way to specify different behavior for
each reference to particular target type. So I would suggest that
AssociationRule should have an attributeName field rather than the targetType
field. The type system would validate/enforce that the type definition has the
attribute specified in the rule.
My experience on other metadata repositories is that the overhead for checking
rules is negligible (especially if the type information is cached as it is in
Atlas) and that processing is dwarfed by the core processing of the operation
on non-trivial data sets - rule checking doesn't show up on the radar when
doing performance profiling.
In the absence of rules, the default behavior will be in effect. For example,
with deletes, the default behavior is that composite references have the
CASCADE delete rule.
I'm not entirely comfortable with the proposal of adding a flag to the
deleteEntities operation which controls whether deletes are cascaded. I think
that behavior should be modeled appropriately. In other words, if the modeler
defines a reference as composite, then they are saying the composite entities
have no meaning on their own and should not live independently of their
container; if the container is deleted then the composite entities should also
be deleted. If that is not the desired behavior, then the modeler should
either define the reference as non-composite; OR, apply a delete rule to that
reference which overrides the default rule of CASCADE and specifies a
DeleteDisconnectRule on that reference. If there is a compelling use case for
overriding the default delete rules at deleteEntities method invocation time,
then I guess it is worth considering extending deleteEntities to allow that. I
am not convinced that such a use case exists... but I'm open to being convinced
:^)
> Support delete cascade efficently
> ---------------------------------
>
> Key: ATLAS-535
> URL: https://issues.apache.org/jira/browse/ATLAS-535
> Project: Atlas
> Issue Type: Sub-task
> Reporter: Suma Shivaprasad
> Fix For: 0.7-incubating
>
>
> Currently there are some limitation in the typesystem and modelling to
> support delete cascades at scale through the isComposite flag
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
