[
https://issues.apache.org/jira/browse/AMBARI-13894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Siddharth Wagle updated AMBARI-13894:
-------------------------------------
Attachment: AMBARI-13894-1.patch
> Refactor delete configs on delete service action
> ------------------------------------------------
>
> Key: AMBARI-13894
> URL: https://issues.apache.org/jira/browse/AMBARI-13894
> Project: Ambari
> Issue Type: Task
> Components: ambari-server
> Affects Versions: 2.0.0
> Reporter: Siddharth Wagle
> Assignee: Siddharth Wagle
> Priority: Critical
> Fix For: 2.1.3
>
> Attachments: AMBARI-13894-1.patch
>
>
> This is not an issue mostly because of the way ClusterConfig and
> ServiceConfig are being used.
> {code}
> @JoinTable(
> name = "serviceconfigmapping",
> joinColumns = {@JoinColumn(name = "service_config_id",
> referencedColumnName = "service_config_id")},
> inverseJoinColumns = {@JoinColumn(name = "config_id",
> referencedColumnName = "config_id")}
> )
> @ManyToMany(cascade = { CascadeType.REMOVE })
> private List<ClusterConfigEntity> clusterConfigEntities;
> {code}
> Today, when you delete Service, the code deletes ServiceConfig entries
> associated with the Service.
> ambari-server/src/main/java/org/apache/ambari/server/state/ServiceImpl.java
> {code}
> void deleteAllServiceConfigs()
> {code}
> This in turn deleted ClusterConfig entities.
> Stack allows a multiple services to be dependent on the same config while
> today ServiceConfig and ClusterConfig are not used that way as UI only shows
> one kind of config on a single page. But if this changes in future then the
> ManyToMany relationship with CASCADE delete may create problem.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
