Additional data purging needed; e.g. RHQ_CONFIG_UPDATE

Thomas Segismont tsegismo at redhat.com
Thu Oct 16 13:21:09 UTC 2014


Sorry, the PR link:
https://github.com/rhq-project/rhq/pull/132

Le 16/10/2014 15:20, Thomas Segismont a écrit :
> Elias, I have CLOSED WONTFIX two of your purge related bugs and fixed
> the four remaining.
>
> The pull request is sent and I'd like you and at least somebody in the
> core team to review it before it's merged.
>
> There are good chances to see the changes in 4.13
>
> Regards,
> Thomas
>
> Le 30/09/2014 21:47, Elias Ross a écrit :
>> On Tue, Sep 30, 2014 at 10:26 AM, Jay Shaughnessy
>> <jshaughn at redhat.com> wrote:
>>>
>>> It is definitely the case that we don't successfully eliminate all
>>> Config
>>> props.  There are certainly orphans.  It has to do with our recursive
>>> config
>>> structure, which is an albatross we haven't been able to shed.
>>>
>>
>> So I came up with 33,000 or so orphans, which isn't too bad, like 5%
>> or so of the total.
>>
>> Here's how I did it, in case you'd like to do it.
>>
>> create table rhq_config_ids ( id number primary key )
>> insert into rhq_config_ids select id from rhq_config
>>
>> -- this took less than a minute
>> delete from rhq_config_ids where id in (
>> select sender_config_id from rhq_alert_notification
>> union
>> select extra_config_id from rhq_alert_notification
>> union
>> select config_id from rhq_bundle_deployment
>> union
>> select configuration_id from rhq_config_group_update
>> -- no property
>> select configuration_id from rhq_config_property
>> union
>> select config_id from rhq_config_template
>> union
>> select configuration_id from rhq_config_update
>> union
>> select configuration_id from rhq_content_source
>> union
>> select configuration_id from rhq_create_res_hist
>> union
>> select configuration_id from rhq_create_res_hist
>> union
>> select configuration_id from rhq_dashboard
>> union
>> select configuration_id from rhq_dashboard_portlet
>> union
>> select config_id from rhq_drift_definition
>> union
>> select config_id from rhq_drift_def_template
>> union
>> select deployment_config_id from rhq_installed_pkg_hist
>> union
>> select parameters_config_id from rhq_operation_history
>> union
>> select results_config_id from rhq_operation_history
>> union
>> select config_id from rhq_package_version
>> union
>> select plugin_config_id from rhq_plugin
>> union
>> select jobs_config_id from rhq_plugin
>> union
>> select config_id from rhq_raw_config
>> union
>> select res_configuration_id from rhq_resource
>> union
>> select plugin_configuration_id from rhq_resource
>> union
>> select bundle_config_id from rhq_resource_type
>> union
>> select configuration_id from rhq_subject
>> )
>>
>> -- this took about 15 minutes
>> delete from rhq_config_ids where id in (
>> select configuration_id from rhq_config_property
>> )
>>
>> Then you just eliminate the entries from rhq_config_ids.
>>
>> You could put this into a (monthly?) job that could fire off. I'm not
>> sure it's worth doing, though.
>> _______________________________________________
>> rhq-devel mailing list
>> rhq-devel at lists.fedorahosted.org
>> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel
>>
>
> _______________________________________________
> rhq-devel mailing list
> rhq-devel at lists.fedorahosted.org
> https://lists.fedorahosted.org/mailman/listinfo/rhq-devel



More information about the rhq-devel mailing list