ambari-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Hurley (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (AMBARI-15058) Schema changes for component history
Date Tue, 16 Feb 2016 18:49:18 GMT

     [ https://issues.apache.org/jira/browse/AMBARI-15058?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Jonathan Hurley updated AMBARI-15058:
-------------------------------------
    Description: 
Create schema and entities to manage upgrade and downgrade history for components. Since we
are pairing the upgrade/downgrade request with a component (and not a service) the associated
table needs to be a 1:1 mapping with cluster component. Currently, the only table tracking
this is the {{servicecomponentdesiredstate}}:

{code}
CREATE TABLE servicecomponent_history(
  id BIGINT NOT NULL,
  component_id BIGINT NOT NULL,
  upgrade_id BIGINT NOT NULL,
  from_stack_id BIGINT NOT NULL,
  to_stack_id BIGINT NOT NULL,
  CONSTRAINT PK_sc_history PRIMARY KEY (id),
  CONSTRAINT FK_sc_history_component_id FOREIGN KEY (component_id) REFERENCES servicecomponentdesiredstate
(id),
  CONSTRAINT FK_sc_history_upgrade_id FOREIGN KEY (upgrade_id) REFERENCES upgrade (upgrade_id),
  CONSTRAINT FK_sc_history_from_stack_id FOREIGN KEY (from_stack_id) REFERENCES stack (stack_id),
  CONSTRAINT FK_sc_history_to_stack_id FOREIGN KEY (to_stack_id) REFERENCES stack (stack_id)
);
{code}

The new {{servicecomponent_history}} will contain mostly FK's to other tables since the {{servicecomponentdesiredstate}}
and the {{upgrade}} table contain all of the information needed. There's no need to data duplication.

  was:Create schema and entities to manage upgrade and downgrade history for components.


> Schema changes for component history
> ------------------------------------
>
>                 Key: AMBARI-15058
>                 URL: https://issues.apache.org/jira/browse/AMBARI-15058
>             Project: Ambari
>          Issue Type: Task
>          Components: ambari-server
>    Affects Versions: 2.4.0
>            Reporter: Jonathan Hurley
>            Assignee: Jonathan Hurley
>            Priority: Critical
>             Fix For: 2.4.0
>
>
> Create schema and entities to manage upgrade and downgrade history for components. Since
we are pairing the upgrade/downgrade request with a component (and not a service) the associated
table needs to be a 1:1 mapping with cluster component. Currently, the only table tracking
this is the {{servicecomponentdesiredstate}}:
> {code}
> CREATE TABLE servicecomponent_history(
>   id BIGINT NOT NULL,
>   component_id BIGINT NOT NULL,
>   upgrade_id BIGINT NOT NULL,
>   from_stack_id BIGINT NOT NULL,
>   to_stack_id BIGINT NOT NULL,
>   CONSTRAINT PK_sc_history PRIMARY KEY (id),
>   CONSTRAINT FK_sc_history_component_id FOREIGN KEY (component_id) REFERENCES servicecomponentdesiredstate
(id),
>   CONSTRAINT FK_sc_history_upgrade_id FOREIGN KEY (upgrade_id) REFERENCES upgrade (upgrade_id),
>   CONSTRAINT FK_sc_history_from_stack_id FOREIGN KEY (from_stack_id) REFERENCES stack
(stack_id),
>   CONSTRAINT FK_sc_history_to_stack_id FOREIGN KEY (to_stack_id) REFERENCES stack (stack_id)
> );
> {code}
> The new {{servicecomponent_history}} will contain mostly FK's to other tables since the
{{servicecomponentdesiredstate}} and the {{upgrade}} table contain all of the information
needed. There's no need to data duplication.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Mime
View raw message