Mryntu

Context Around this Code: I am making a schedulable class run each Sunday to track a couple of metrics important to the team.

Question: I am looking to consolidate DML operations and a big part of this is understanding pass by reference vs pass by value.

I want to pass the salesOps user object to the method SDREfficiencyLastWeek. I made the return type void, because I figured that I will be passing this by reference and I can make all the updates in the method without having to anything.

Why I am confused:

https://developer.salesforce.com/blogs/developer-relations/2012/05/passing-parameters-by-reference-and-by-value-in-apex.html
I read the above article and am thrown off by the following statement:

"Non-primitive data type arguments, such as sObjects, are also passed into methods by value. "

If the object is indeed passed by reference, then the query for the salesOps user in my code should be sufficient enough to edit all fields on that object without actually having to state each field in the query.

global class SDREfficientMetricsSchedulable implements Schedulable 

 global void execute(SchedulableContext sc) 
 
 User salesOps = [SELECT ID FROM USER WHERE id = '0056A000002Z3p9QAC'];
 List<String> queries = new List<String>();

 String contactsWorked_lastWeek = 'select count(id) results from contact where LastActivityDate = last_week';
 queries.add(contactsWorked_lastWeek);

 String demosSet_lastWeek = 'select count(id) results from form__c where CreatedDate = last_week';
 queries.add(demosSet_lastWeek);

 String demosCompleted_lastWeek = 'select count(id) results from opportunity where (stagename = 'Unqualified Demo Completed' OR stagename = 'Qualified Demo Completed' ) and RecordTypeId = '0126A000000yudDQAQ' and CloseDate = last_week';
 queries.add(demosCompleted_lastWeek);

 String qualifiedDemos_lastWeek = 'select count(id) results from opportunity where RecordTypeId = '0126A0000004Ao6QAE' and isclosed = false and SDR_Owner__c != null and CreatedDate = last_week';
 queries.add(qualifiedDemos_lastWeek);

 String closedWon_lastWeek = 'select count(id) results from opportunity where RecordTypeId = '0126A0000004Ao6QAE' and iswon = true and SDR_Owner__c != null and CloseDate = last_week';
 queries.add(qualifiedDemos_lastWeek);



 SDREfficiencyLastWeek(queries, salesOps);

 update salesOps;
 


 public void SDREfficiencyLastWeek(List<String> queries, User salesOps )
 



 

There's two different meanings of "reference," which is probably the source of confusion even with veteran developers, especially in regards to Apex. Some developers consider passing a variable's memory in to a parameter as "by reference", and literal values as "by value". We see this frequently in languages like C:

#include <stdio.h>

void multiplyByTwoRef(int *source) 

 // We're modifying the caller's value!
 *source = *source * 2;

int multiplyByTwo(int source) 
 // We're modifying a local copy here.
 source = source * 2;
 return source;


int main()


 int myVar = 5;
 multiplyByTwoRef(&myVar); // Here, & means "pass memory address"; this is a reference
 printf("%i", myVar);
 printf("%i", multiplyByTwo(myVar)); // Here, we output 20 (10 * 2)
 printf("%i", myVar); // But we output 10 here again, myVar was not modified
 return 0;

In Apex, of course, this doesn't happen; we can't access memory pointers directly, so people tend to call Apex pass-by-value. However, that is simply not true in the most literal sense.

Consider the following code:

System.debug(Limits.getHeapSize());
Integer x1 = 5, x2 = x1, x3 = x1, x4 = x1;
System.debug(Limits.getHeapSize());

If you check the debug logs, you'll notice that only 8 bytes were allocated. It's also worth noting that an Integer is 8 bytes. However, we allocated x1, x2, x3, and x4, so we should have 32 bytes of heap usage, right? As it happens, this isn't true; x2, x3, and x4 all have a reference to x1.

You can see the difference if we change the code:

System.debug(Limits.getHeapSize());
Integer x1 = 5, x2 = 5, x3 = 5, x4 = 5;
System.debug(Limits.getHeapSize());

Now, we've allocated four Integer objects in memory, although they all have the same value, they are not literally the same object.

In Apex, all variables point to an area in heap (or are null). Variables themselves are references. All the time. Apex hides this fact from developers by appearing to have pass-by-value for primitives and pass-by-reference for objects, but that's all it is, an illusion.

The only way one could consider Apex to be pass-by-value is to say that Apex always passes the memory addresses (values) of objects on the heap.

So, to answer your question, yes, if you pass in an sObject record to a method, you're passing a reference to the object on the heap. Any changes you make to the object will affect the caller's version of the object. Passing in a List, or a Map, or a custom class instance, will all affect the original object on the heap.

Note that you can't modify the parameter itself, as that would lose the reference on the heap. It won't affect the original caller's version, because you're creating a new object in memory. To compare:

public static void setFirstName(Contact record, String name) 
 // This WILL affect the caller's object
 record.FirstName = name;
 record = new Contact();
 // This won't affect the caller's object
 record.FirstName = name.repeat(2);

// ...
Contact record = new Contact();
setFirstName(record, 'Sally');

The important thing to remember is that primitives are immutable, and cannot be directly modified. You may as well consider these pass-by-value, even though we're really passing references. Everything else is pass-by-reference, since modifying the object in the parameter will affect the original.

When Apex code calls synchronous Apex code the non-primitive objects are passed by reference - a change to the content of a list, map, set, SObject or custom Apex object is reflected in the caller's context too.

I suggest that the "pass by value" statement in the article is referring to cases such as scheduled apex, batches etc. (asynchronous execution) where the state of the object is serialized to the database, and deserialized back into an object when that code is about to be executed. In this sense the original state of the object (such as a batch) is not impacted by the later, asynchronous execution of the processing in that object.

When you query an object from the DB into an SObject in Apex, the SObject in Apex is only populated with the fields you actually request in the query. All other fields are unset (and an attempt to directly read them will fail with an exception - you can avoid this error by getting the populated fields map and interrogating this map instead). Note, however, that you can set any fields you like in that SObject, whether or not you queried them, and update the object in the DB using that modified state.