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?
trigger triggercontext
add a comment |
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?
trigger triggercontext
add a comment |
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?
trigger triggercontext
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
trigger triggercontext
asked Nov 14 at 20:09
Sandeep Kamlesh Mishra
213
213
add a comment |
add a comment |
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
.
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 at 3:36
add a comment |
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 {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationType
but now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 at 20:22
add a comment |
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
add a comment |
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
.
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 at 3:36
add a comment |
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
.
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 at 3:36
add a comment |
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
.
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
.
answered Nov 14 at 20:18
Adrian Larson♦
103k19110233
103k19110233
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 at 3:36
add a comment |
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 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 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 at 3:36
add a comment |
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 {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationType
but now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 at 20:22
add a comment |
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 {
// ...
}
// ...
}
1
I was going to add in something abouttrigger.operationType
but now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 at 20:22
add a comment |
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 {
// ...
}
// ...
}
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 {
// ...
}
// ...
}
answered Nov 14 at 20:18
David Reed
26k51645
26k51645
1
I was going to add in something abouttrigger.operationType
but now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 at 20:22
add a comment |
1
I was going to add in something abouttrigger.operationType
but now that you have it here, I'll leave my answer as is.
– Adrian Larson♦
Nov 14 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 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 at 20:22
add a comment |
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
add a comment |
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
add a comment |
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
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
answered Nov 14 at 20:16
Pranay Jaiswal
10.9k31951
10.9k31951
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
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
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
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