atlas-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Kantor (JIRA)" <>
Subject [jira] [Commented] (ATLAS-535) Support delete cascade efficently
Date Tue, 01 Mar 2016 00:03:18 GMT


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:
>             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

View raw message