Governor limits involving cascaded deletes?

Question

I'm writing a job to bulk delete records from my database.

I've already seen this question: Cascade delete limits? But it does tell me how the deletion limits are affected.

The object whose records I'm deleting are A__c. Actually, through master-detail, A__c has a child object B__c.

A__c
 |
B__c

I know that, for records without any children, the governor limits for deleting records are 10,000 (I believe, please correct me if I am wrong). Does this 10,000 limit take into account cascaded deletions?

For example, say I have 5000 A__c records, and each A__c record has 1 B__c record as its child. I've also set the relationship such that cascaded deletion occurs. Thus, on deleting 5000 A__c records, the 5000 associated B__c records will also be removed. Does this mean I have hit the governor limit because I deleted 10,000 records in total? Or am I still good for more?

Now, let's say B__c has a child C__c, and C__c has a child D__c. How does the situation change?

Answer 1

Your last scenario (A deletes B, B deletes C, C deletes D) won't happen automatically, as we can't have master-detail relationships greater than two levels deep at this point (so, at most, we'd have A deletes B, B deletes C). Regardless, there's still limits to what we can do.

There's really 2 different limits for the number of rows we can modify per transaction. The first limit is the one shown in governor limits: we can affect no more than 10,000 rows of data directly in a single transaction (e.g. by way of triggers). There's a second limit that isn't called out anywhere I've seen, but it happens to be 50,000 rows. This limit is the maximum number of records that can be modified as the result of a transaction, including any parent and child records affected by a DML operation.

So, to change your scenario slightly, if you have a single A with 50,000 B records, you can't delete A, because the total number of affected rows would be 50,001 (50,000 B plus 1 A). In that case, you'd be forced to delete at least one B record in a separate transaction before you could delete A. This is one reason why it's recommended that you don't stack too many children on a single parent.

In your first example, 5,000 A each with a single B, you would still have 5,000 explicit DML operations remaining, and 40,000 total affected rows remaining. In the case of 5,000 A each with a single B, and each of those with a single C, you'd still have 5,000 DML rows remaining, and 35,000 total affected rows remaining.

This 50,000 row limit is apparently treated like a governor limit, so if you exceed that number, your code will immediately terminate without any chance to rescue it via try-catch. In that case, the best you can really do is advise your users/clients not to have that much data skew.