Bug 535485 - (RHQ-2175) remove recursive cascading from config-related tables
remove recursive cascading from config-related tables
Status: CLOSED NEXTRELEASE
Product: RHQ Project
Classification: Other
Component: Database (Show other bugs)
unspecified
All All
high Severity medium (vote)
: ---
: ---
Assigned To: Joseph Marques
Pavel Kralik
http://jira.rhq-project.org/browse/RH...
: Improvement
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-06-25 05:19 EDT by Joseph Marques
Modified: 2013-04-30 19:32 EDT (History)
1 user (show)

See Also:
Fixed In Version: 1.3
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed:
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Joseph Marques 2009-06-25 05:19:00 EDT
look at config-schema.xml inside the rhq_config_property table.  there is this comment "<!-- Dual cascade path to RHQ_CONFIG_PROPERTY causes constraint creation errors on SQL Server, see http://support.microsoft.com/kb/321843 -->"  so, if we remove the oncascade properties for parent_list_id and parent_map_id, then we can remove the "getOnDelete() { return null; }" implementation in SQLServerColumn inside of dbutils.  as it turns out, the use cases for deleting a resource will naturally take care of things without the need for additional cascade rules between the properties themselves.  
Comment 1 Joseph Marques 2009-06-25 05:27:02 EDT
rev4181 - remove recursive cascade rules from configuration properties; 
this allows re-enablement of ondelete rules for SQLServerColumn impl in dbutils; 
Comment 2 Joseph Marques 2009-07-27 12:27:01 EDT
once upon a time we used hibernate cascading rules to delete config.  this would ensure that when i delete a config, that all of its properties were deleted...and if those properties were maps or lists, that the contained properties would get deleted...and so on.

performance testing against our resource uninventory functionality showed that this was one of the slow parts of the removal process.  so, we moved the cascade rules to the database in the form of "oncascade" definitions on particular columns.  this worked for postgres and oracle (and even h2) but didn't work for sql server (see knowledge base article from the description).

considering that 2.3 now has very fast uninventory (due to performing most of the work asynchronously), we could revert back to the original, hibernate annotation-based, cascade solution.  although this /did/ work, it caused weird errors when removing resources on oracle (saw and reported by Ian in RHQ-2218).

so, the final solution ended up being 2-fold:

1) it brought back the recursive, oncascade definition for the rhq_config_property table - and this is used for databases that support recursive, oncascade definitions
2) for databases that don't support recursive definitions (sql server) the oncascade property is ignored, and extra code was written at the SLSB layer to do the additional work during uninventory that the oncascade definition would have taken care of

repro steps - inventory a bunch of resources, make sure you edit both plugin configuration and resource configuration on several of them, try to uninventory all of your resources...you should see no errors or warnings in the log whatsoever, and the uninventory should complete properly.  when the async resource deleter comes along to clean things up (within 5 mins after the uninventory action) that should also produce no warnings / errors.  make sure you do this on both postgres and oracle.
Comment 3 Pavel Kralik 2009-08-05 13:42:52 EDT
QA verified with Oracle/Postgres. r4650
Comment 4 Red Hat Bugzilla 2009-11-10 15:59:18 EST
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2175
This bug is related to RHQ-2142

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