Update same record in after insert/update in a trigger context

Question

I searched a bit for some informations about the need to make an update on a record in after insert/update trigger context. I found that the common feedback was to move the Business logic in before context, which is a best practice most of the times.

Anyway, As a programmer I would understand how to execute an update in after insert/update context

• this because the formula field are updated
• I can be sure that all the before operations has processed properly and without issues.

In this situation what I have to keep in mind so to avoid issues? With the new DML I'm going to fire a new trigger (before and after), and we hve two triggers on same records that execute in the same context. So what happen to the variables:

• Trigger.Old
• Trigger.New

Those are the new variables or the first trigger, or the variables of the second trigger?

How can I controll/master the operations of the two triggers (and avoid an infinite loop )

I'm writing this question so to get a better explaination of this situation, I figured out that there is a poor documentation.

thnks in advance.

Answer 1

In a Before Trigger, Trigger.new and Trigger.old both contain the same values. However, in a Before Trigger, one can operate on the values in Trigger.new and change their values.

In an After Trigger, Trigger.new will contain the the Id's and field values of any records that have been changed by a DML operation. The values contained in Trigger.new can be compared to Trigger.old in order to determine which records meet the criteria for firing the trigger and need to be operated on. Unlike in a Before Trigger, the values in Trigger.new cannot be changed or edited.

Recursion is frequently handled by setting a boolean static variable to "true" when a trigger initially fires. Upon entry to the trigger, that static variable is tested. If the boolean is "true" when re-entered in the same execution context, then the trigger is exited rather than allowing it to run again. There are a variety of methods for handling recursion and this is probably the most common.

Edit

I think what you're looking for are trigger patterns such the one described by Dan Appleman in his book Advanced Apex Programming for Salesforce and Force.com (Note: sample code available from App Exchange as an unmanaged package), Hari Krishan's Architecture Framework to Handle Triggers or Kevin O'Hara's Trigger Framework among others that exist or have been espoused which you can find through searching that go beyond the Trigger Pattern for Tidy, Streamlined, Bulkified Triggers.

Using a Main Dispatcher class, these approaches take charge of trigger execution, extending it to an enterprise level application that's scalable, can have it's own diagnostics classes and error reporting, utilize common helper classes and much more. One can also control trigger execution order; something that can't be done with triggers that operate independently of one other without some kind of central control for each object or, as is the case with some architures, potentially for related objects as well.

Discussing them in depth is beyond the scope of this forum, but I'll point you to at least a few posts that you may find relevant including: Controlling Trigger Execution, One Trigger Approach: Any Logic in Trigger?, Difficulties with Appleman's Trigger Classes and General trigger bulkification - best practices.