[
https://issues.apache.org/jira/browse/ATLAS-535?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15168482#comment-15168482
]
Hemanth Yamijala commented on ATLAS-535:
----------------------------------------
[~suma.shivaprasad]
In all three options, there will be a need to delete a large number of entries.
I think we should look at solving the problem independent of the option we
choose. For e.g. we could implement a lazy delete in the background - a
strategy used in many systems for handling a similar problem.
Option 3 looks good, generic and extensible. It could be a way to subsume the
'flags' that we currently have in the type system with a mechanism that seems
cleaner and more declarative. The mechanics need to be thought through a little
more - who can define new AssociationRules, how, which rules are 'system'
defined and can they be redefined, when would the system look at
AssociationRules - we would need to look at them every time and depending on
the operation see if there's one that needs to be picked up - would this add an
overhead for all operations, etc.
I am currently torn between 2 and 3. 2 is an easy extension and feels easy to
implement, but I am worried that with isComposite and isInverseComposite, would
users be confused about which to use when? The one consolation is that it is
easy to migrate 2 to 3 in case we decide to move to that once we understand it
better.
> 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)
