I am very new in the world of salesforce. Thanks a billion for this session about the recursive scenario in salesforce trigger and how to prevent it. I did a little modification on the first solution using boolean static variable and the idea is similar to using integer counter variable. So it is a mix of two 1. Instead of static integer variable, I use boolean static variable to avoid trigger recursion. 2. Two trigger shouldn't reuse the same static variable for same purpose. By doing this I can avoid MAX_COUNTER variable in case of chaining trigger execution due to multiple sObject update from inside a trigger 3. Before exiting from the trigger re-initialize the boolean variable back to it's original value I couldn't quite understand a. Partial retry problem b. Unit testing problem well - I am a newbie and long way to go to learn about those topics. If the integer variable solution address both of these issues then it also addressed. Because it is same solution but with different flavour
Comparing old and new objects with 800+ fields will be a heavy check. It will lead to CPU time limit too soon. What do you think? Do we have any clean solution for that other than comparing particular fields?
Yeah right... I think comparing all the fields would increase the CPU time... we can check for which fields to not compare. A custom setting with Boolean field for bypassing is any way better than using a class level static variable. It will also help in unit tests where static variable always resets.
I am very new in the world of salesforce. Thanks a billion for this session about the recursive scenario in salesforce trigger and how to prevent it.
I did a little modification on the first solution using boolean static variable and the idea is similar to using integer counter variable. So it is a mix of two
1. Instead of static integer variable, I use boolean static variable to avoid trigger recursion.
2. Two trigger shouldn't reuse the same static variable for same purpose. By doing this I can avoid MAX_COUNTER variable in case of chaining trigger execution due to multiple sObject update from inside a trigger
3. Before exiting from the trigger re-initialize the boolean variable back to it's original value
I couldn't quite understand a. Partial retry problem b. Unit testing problem well - I am a newbie and long way to go to learn about those topics. If the integer variable solution address both of these issues then it also addressed. Because it is same solution but with different flavour
Thank You! Trigger is the name of the game.
hi, where can i find the code of this example?
Comparing old and new objects with 800+ fields will be a heavy check. It will lead to CPU time limit too soon. What do you think? Do we have any clean solution for that other than comparing particular fields?
Yeah right... I think comparing all the fields would increase the CPU time... we can check for which fields to not compare.
A custom setting with Boolean field for bypassing is any way better than using a class level static variable. It will also help in unit tests where static variable always resets.
Sfdc fox in the building