Bug 536582 (RHQ-917) - updating operation with a name change requires there to be 0 operation history rows
Summary: updating operation with a name change requires there to be 0 operation histor...
Keywords:
Status: CLOSED NOTABUG
Alias: RHQ-917
Product: RHQ Project
Classification: Other
Component: Core Server
Version: 1.1
Hardware: All
OS: All
medium
medium
Target Milestone: ---
: ---
Assignee: RHQ Project Maintainer
QA Contact:
URL: http://jira.rhq-project.org/browse/RH...
Whiteboard:
Depends On:
Blocks: rhq_triage
TreeView+ depends on / blocked
 
Reported: 2008-10-02 03:31 UTC by John Mazzitelli
Modified: 2010-10-05 13:37 UTC (History)
1 user (show)

Fixed In Version:
Clone Of:
Environment:
Last Closed: 2010-10-05 13:37:47 UTC
Embargoed:


Attachments (Terms of Use)

Description John Mazzitelli 2008-10-02 03:31:00 UTC
If I update an operation definition, specifically, if I changed the name of an existing operation, the plugin metadata manager will treat this as a new operation with the "old" operation (with the previous name) needing to be deleted. However, to delete, it means that operation must not have any operation history rows related to it.  If the old operation has been invoked before and the operation history still exists, a constraint violation will occur when the deletion is attempted.

Need to move the relationship of the history rows to point to the new operation definition so the old op definition can be deleted.

Comment 1 Greg Hinkle 2008-10-02 03:34:28 UTC
The name is the key, so if you change the name the system has to assume the old one is deleted and this is a new one.

My idea would be to have old operations be marked "obsolete" instead of trying to delete them. Then we can keep the history available, but filter them from the runnable operations.

Comment 2 Red Hat Bugzilla 2009-11-10 21:19:35 UTC
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-917


Comment 3 wes hayutin 2010-02-16 16:51:52 UTC
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs.

keyword:
new = Tracking + FutureFeature + SubBug

Comment 4 wes hayutin 2010-02-16 16:57:58 UTC
making sure we're not missing any bugs in rhq_triage

Comment 5 Corey Welton 2010-10-05 13:37:47 UTC
Closing, works as expected


Note You need to log in before you can comment on or make changes to this bug.