5

A while back I had a trigger issue where I needed a trigger operation to execute exclusively on the second update or an update after an insert.

So I had some code like this:
Trigger Handler Class

public class FieldUpdateTrigger
{
    private static Boolean _canProcessRecords = false;
    private static Boolean _hasProcessedRecords =  false;

    private static Boolean RecordsAreReadyToProcess { get { return _canProcessRecords && !_hasProcessedRecords; } }
    private static Boolean FieldsHaveBeenUpdatedByFieldUpdate 
    {
        get { return !_canProcessRecords && !_hasProcessedRecords; }
    }

    private static void ProcessRecordsAfterFireldUpdate(List<sObjects> recordsOfInterest)
    {
        //Process the records with values populated by a field update
        _hasProcessedRecords = true;
    }

    public static void ProcessMyExamples(List<sObject> recordsOfInterest)
    {
        if(FieldsHaveBeenUpdatedByFieldUpdate)
        {
            _canProcessRecords = true;
            return;
        }

        if(RecordsAreReadyToProcess)
            ProcessRecordsAfterFireldUpdate(recordsOfInterest);
    }
}

And the trigger would look something like this:
Trigger Code

trigger ExapleTrigger on Example__c (before insert, before update)
{
    if(trigger.isBefore && (trigger.isInsert || trigger.isUpdate)
        FieldUpdateTrigger.ProcessMyExamples(trigger.new);
}

Now everything would work fine, until I started loading data into the Data Loader.

Apparently, it would only process 200 records (a known batch size) and ignore the rest of the records that were inserted.

This was due to my understanding, which must have been uninformed, that every batch (every 200 records) would get it's own execution context. Thus, the _hasProcessedRecords flag would be set to false again, but that doesn't happen.

My quick solution was to reset the _hasProcessedRecords flag when I check to see if fields have been updated by a field update, but I was curious why I had to do that when this should have been reset.

Also, I am curious on any solutions that more eloquently deal with triggers that need values after a field update.

4

Static variables will live through the entire lifetime of your apex transaction.

From the documentation:

Use static variables to store information that is shared within the confines of the class. All instances of the same class share a single copy of the static variables. For example, all triggers that are spawned by the same transaction can communicate with each other by viewing and updating static variables in a related class. A recursive trigger might use the value of a class variable to determine when to exit the recursion.

  • So now that you have easy cleared that up. I'm curious on how I would alternate my flags. Would it be safe to assume that each batch goes through their initial insert or update, then a final update for the field update? Example being: 400 records are inserted. The first 200 goes through the insert check, these records then go though an update which uses the field update. Then the next and final 200 go through the same process. – Programmable Medley Sep 19 '14 at 17:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.