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.
rev4181 - remove recursive cascade rules from configuration properties; this allows re-enablement of ondelete rules for SQLServerColumn impl in dbutils;
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.
QA verified with Oracle/Postgres. r4650
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-2175 This bug is related to RHQ-2142