Uninventory does not set the status to DELETED. It sets the status to
UNINVENTORIED. The async job looks for resources where Resource.agent is
null to determine which resources to purge. When
ResourceFactoryManagerBean completes the resource deletion, it set the
resource's inventory status to DELETED, but it does not set
Resource.agent to null. Other than for auditing purposes, I don't
understand the reason for having the DELETED status. If we have audit
trails that are independent of the resources to which they are
associated, then I believe we can altogether do away with DELETED. By
independent, I mean no explicit FK. And since the audit trail could
outlive the associated resource, we'd probably want to store something
more that the resource id in each audit trail row.
On 3/14/11 2:36 PM, John Mazzitelli wrote:
DELETED was also so we can uninventory very fast.
Before DELETED, if you would uninventory a platform, the UI was
extremely slow and many times would timeout.
Uninventory now just does a bulk update to flip the status to DELETED
and *poof* resources no longer show up in the UI and it is very fast.
Note that there is an async job that is supposed to actually delete
resources (these jobs can take long to complete and Joe wrote it so it
wouldn't tx timeout, knowing that this stuff can take a while).
the flag for this async delete job is a null agent.
come to think of it, I thought whenever a resource is flagged as DELETE
status, the agent is also nulled out. Thus, now that I think about it,
these resources should be removed at some point (losing audit, yes).
_______________________________________________
rhq-devel mailing list
rhq-devel(a)lists.fedorahosted.org
https://fedorahosted.org/mailman/listinfo/rhq-devel