[
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)
