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












2















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



























    2















    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

























      2












      2








      2








      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 Nov 14 '18 at 20:09









      Sandeep Kamlesh MishraSandeep Kamlesh Mishra

      213




      213






















          3 Answers
          3






          active

          oldest

          votes


















          8














          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
            Nov 15 '18 at 3:36



















          3














          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
            Nov 14 '18 at 20:22



















          2














          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',
            autoActivateHeartbeat: false,
            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









            8














            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
              Nov 15 '18 at 3:36
















            8














            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
              Nov 15 '18 at 3:36














            8












            8








            8







            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 Nov 14 '18 at 20:18









            Adrian LarsonAdrian Larson

            108k19115244




            108k19115244













            • 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
              Nov 15 '18 at 3:36



















            • 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
              Nov 15 '18 at 3:36

















            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
            Nov 15 '18 at 3:36





            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
            Nov 15 '18 at 3:36













            3














            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
              Nov 14 '18 at 20:22
















            3














            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
              Nov 14 '18 at 20:22














            3












            3








            3







            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 Nov 14 '18 at 20:18









            David ReedDavid Reed

            35.7k72154




            35.7k72154








            • 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
              Nov 14 '18 at 20:22














            • 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
              Nov 14 '18 at 20:22








            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
            Nov 14 '18 at 20:22





            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
            Nov 14 '18 at 20:22











            2














            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




























              2














              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


























                2












                2








                2







                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 Nov 14 '18 at 20:16









                Pranay JaiswalPranay Jaiswal

                16.8k32755




                16.8k32755






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Salesforce Stack Exchange!


                    • Please be sure to answer the question. Provide details and share your research!

                    But avoid



                    • Asking for help, clarification, or responding to other answers.

                    • Making statements based on opinion; back them up with references or personal experience.


                    To learn more, see our tips on writing great answers.




                    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

                    The Sandy Post

                    Danny Elfman

                    Pages that link to "Head v. Amoskeag Manufacturing Co."