Why does Salesforce has Trigger.isInsert or Trigger.isUpdate when Trigger.old !=Null would have worked?





.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty{ margin-bottom:0;
}






up vote
2
down vote

favorite












Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap



Example:



We always use it in below scenarios:




Scenarios 1:
if(Trigger.isInsert){
method1();
}



Scenarios 2:
if(Trigger.old == null){
method1();
}




In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?










share|improve this question




























    up vote
    2
    down vote

    favorite












    Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap



    Example:



    We always use it in below scenarios:




    Scenarios 1:
    if(Trigger.isInsert){
    method1();
    }



    Scenarios 2:
    if(Trigger.old == null){
    method1();
    }




    In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?










    share|improve this question
























      up vote
      2
      down vote

      favorite









      up vote
      2
      down vote

      favorite











      Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap



      Example:



      We always use it in below scenarios:




      Scenarios 1:
      if(Trigger.isInsert){
      method1();
      }



      Scenarios 2:
      if(Trigger.old == null){
      method1();
      }




      In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?










      share|improve this question













      Salesforce has context variables like Trigger.IsInsert just to understand if trigger is running for Insert scenarios. However, we could always have got this information by doing the NULL check on Trigger.Old or Trigger.OldMap



      Example:



      We always use it in below scenarios:




      Scenarios 1:
      if(Trigger.isInsert){
      method1();
      }



      Scenarios 2:
      if(Trigger.old == null){
      method1();
      }




      In both the scenarios, decision/control statements are same and have the same complexity. What's the benefit of having it then?







      trigger triggercontext






      share|improve this question













      share|improve this question











      share|improve this question




      share|improve this question










      asked yesterday









      Sandeep Kamlesh Mishra

      212




      212






















          3 Answers
          3






          active

          oldest

          votes

















          up vote
          8
          down vote













          First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.



          Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.






          share|improve this answer





















          • To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
            – Carl
            yesterday


















          up vote
          3
          down vote













          There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.



          Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write



          if (Trigger.isInsert) {


          rather than



          if (Trigger.new != null && Trigger.old == null) {


          In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like



          switch on (Trigger.operationType) {
          when BEFORE_INSERT {
          // do stuff...
          }
          when AFTER_UPDATE {
          // ...
          }
          // ...
          }





          share|improve this answer

















          • 1




            I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
            – Adrian Larson
            yesterday


















          up vote
          2
          down vote













          You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.



          Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.




          Trigger.old Returns a list of the old versions of the sObject records.
          This sObject list is only available in update and delete triggers.



          Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm






          share|improve this answer





















            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "459"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














             

            draft saved


            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239403%2fwhy-does-salesforce-has-trigger-isinsert-or-trigger-isupdate-when-trigger-old%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes








            up vote
            8
            down vote













            First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.



            Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.






            share|improve this answer





















            • To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
              – Carl
              yesterday















            up vote
            8
            down vote













            First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.



            Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.






            share|improve this answer





















            • To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
              – Carl
              yesterday













            up vote
            8
            down vote










            up vote
            8
            down vote









            First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.



            Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.






            share|improve this answer












            First of all, you get significantly clearer semantics when you check if (trigger.isInsert) rather than checking if (trigger.old == null). It also adds consistency and completeness with the isBefore and isAfter attributes, which you could not check by inspecting the collection values.



            Second of all, checking for the presence of trigger.new and trigger.old does not suffice to uniquely check all operations. For example, both before insert and before undelete have trigger.old == null && trigger.new != null.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered yesterday









            Adrian Larson

            102k19110232




            102k19110232












            • To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
              – Carl
              yesterday


















            • To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
              – Carl
              yesterday
















            To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
            – Carl
            yesterday




            To add, if the conditions for inserting change, then having those qualities in a function means the end user doesn't have to change their code at all.
            – Carl
            yesterday












            up vote
            3
            down vote













            There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.



            Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write



            if (Trigger.isInsert) {


            rather than



            if (Trigger.new != null && Trigger.old == null) {


            In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like



            switch on (Trigger.operationType) {
            when BEFORE_INSERT {
            // do stuff...
            }
            when AFTER_UPDATE {
            // ...
            }
            // ...
            }





            share|improve this answer

















            • 1




              I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
              – Adrian Larson
              yesterday















            up vote
            3
            down vote













            There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.



            Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write



            if (Trigger.isInsert) {


            rather than



            if (Trigger.new != null && Trigger.old == null) {


            In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like



            switch on (Trigger.operationType) {
            when BEFORE_INSERT {
            // do stuff...
            }
            when AFTER_UPDATE {
            // ...
            }
            // ...
            }





            share|improve this answer

















            • 1




              I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
              – Adrian Larson
              yesterday













            up vote
            3
            down vote










            up vote
            3
            down vote









            There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.



            Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write



            if (Trigger.isInsert) {


            rather than



            if (Trigger.new != null && Trigger.old == null) {


            In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like



            switch on (Trigger.operationType) {
            when BEFORE_INSERT {
            // do stuff...
            }
            when AFTER_UPDATE {
            // ...
            }
            // ...
            }





            share|improve this answer












            There are more trigger events than just insert and update. Trigger.old is also available in delete triggers (see Trigger Context Variables), so comparing Trigger.old to null is not sufficient by itself to identify which trigger event we are running in. Likewise, Trigger.new is available (without Trigger.old) in both insert and undelete context.



            Even if we could derive the trigger event by making various comparisons between Trigger.new, Trigger.old, and null, it's clearer and more semantically meaningful to just write



            if (Trigger.isInsert) {


            rather than



            if (Trigger.new != null && Trigger.old == null) {


            In fact, we now have Trigger.operationType to even further streamline this type of code with constructs like



            switch on (Trigger.operationType) {
            when BEFORE_INSERT {
            // do stuff...
            }
            when AFTER_UPDATE {
            // ...
            }
            // ...
            }






            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered yesterday









            David Reed

            25.1k51644




            25.1k51644








            • 1




              I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
              – Adrian Larson
              yesterday














            • 1




              I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
              – Adrian Larson
              yesterday








            1




            1




            I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
            – Adrian Larson
            yesterday




            I was going to add in something about trigger.operationType but now that you have it here, I'll leave my answer as is.
            – Adrian Larson
            yesterday










            up vote
            2
            down vote













            You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.



            Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.




            Trigger.old Returns a list of the old versions of the sObject records.
            This sObject list is only available in update and delete triggers.



            Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm






            share|improve this answer

























              up vote
              2
              down vote













              You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.



              Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.




              Trigger.old Returns a list of the old versions of the sObject records.
              This sObject list is only available in update and delete triggers.



              Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm






              share|improve this answer























                up vote
                2
                down vote










                up vote
                2
                down vote









                You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.



                Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.




                Trigger.old Returns a list of the old versions of the sObject records.
                This sObject list is only available in update and delete triggers.



                Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm






                share|improve this answer












                You can get Trigger.Old in Update and Delete context, so you cannot guarantee its insert just by adding a null check on Trigger.old.



                Thats where isInsert ,isDelete,isUpdate,isUndelete comes in picture.




                Trigger.old Returns a list of the old versions of the sObject records.
                This sObject list is only available in update and delete triggers.



                Source: https://developer.salesforce.com/docs/atlas.en-us.apexcode.meta/apexcode/apex_triggers_context_variables.htm







                share|improve this answer












                share|improve this answer



                share|improve this answer










                answered yesterday









                Pranay Jaiswal

                10.5k31950




                10.5k31950






























                     

                    draft saved


                    draft discarded



















































                     


                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsalesforce.stackexchange.com%2fquestions%2f239403%2fwhy-does-salesforce-has-trigger-isinsert-or-trigger-isupdate-when-trigger-old%23new-answer', 'question_page');
                    }
                    );

                    Post as a guest















                    Required, but never shown





















































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown

































                    Required, but never shown














                    Required, but never shown












                    Required, but never shown







                    Required, but never shown







                    Popular posts from this blog

                    AnyDesk - Fatal Program Failure

                    How to calibrate 16:9 built-in touch-screen to a 4:3 resolution?

                    QoS: MAC-Priority for clients behind a repeater