GlideRecord Glimmerings: Destructive Impulses...

[SlightlyLoony]

[asset|aid=344|format=Small|formatter=asset_lightbox|title=destructive_god.jpg|width=150|height=150|align=right]Wanton destruction is generally a bad thing (though fun to watch on a movie, if the special effects are good). Carefully controlled destruction can be a good thing — especially if you need to get rid of some records in a database table.

For example, suppose your company had a datacenter on the Deepwater Horizon drill rig that burned and sank earlier this year. Your people got off ok (unlike the unfortunate 11 who died in the accident), but your equipment burned, then sank under a mile of salt water. Now your boss wants you to get rid of all these computers (950 of them). You could go delete them one page at at time, but that would be very tedious. You'd like to write a script to do it, but how? If this question (or a similar one) has been keeping you awake at night, this post's for you!

Well, if you happen to know about the deleteRecord() method on GlideRecord, you might try something like this:

var gr = GlideRecord('cmdb_ci_computer');
gr.addQuery('location.name', 'Deepwater Horizon');
gr.query();
while (gr.next())
   gr.deleteRecord();

And that would work just fine. But there's an even easier way, like this:

var gr = GlideRecord('cmdb_ci_computer');
gr.addQuery('location.name', 'Deepwater Horizon');
gr.deleteMultiple();

This method can be much, much faster, as it allows the computer to work on big chunks of data at once.

Whenever you write scripts that use either of the delete methods on GlideRecord, you'll want to be very, very careful. A small mistake can have rather dramatic consequences. Consider:

var gr = GlideRecord('cmdb_ci');
gr.deleteMultiple();

What does this script do? Why, it will delete your entire CMDB! It seems likely that your boss would not be impressed by this. Two lines of code, one click...and you've got the proverbial resumé-generating event!

Why does deleting records sometimes seem so slow? It's because there can a lot of work to do! How much work depends on just which table you're deleting from. For example, if you delete a computer (as in this example), it isn't just that computer record that gets deleted — there are related records (disks, running processes, network adapters, etc.) that will also be deleted. To find all those related records, every table that might possibly have related records in it must be searched to see if there actually are any. For tables like the computer table (any CI, actually), there are dozens and dozens of such possibly related tables, so it takes time.

There are actually two different things that can happen when a related record is detected. Many such records (like the disk or network adapter in our example) are simply deleted as well. Other records simply have their reference to the deleted record cleared. This is what happens with references to deleted CIs in incidents, for instance. You most likely wouldn't want to delete an incident that refers to a CI that happened to be deleted. This behavior is controlled by a field in the dictionary record for each reference field. This field is named "Reference cascade rule" (you may have to personalize the dictionary form to see it). If this field is blank or "clear", the behavior is to clear the reference. If the field is "delete", the behavior is to delete the record with the reference.