2

This question is more about with approach is ideal to follow.

Scenario: I need to udpate a field value in some of the records once every week. Should the logic to update the field be present directly in the Schedule class or should I have batch apex and then schedule that?

For example:

public class ScheduleApex implements schedulable {
    public void execute(SchedulableContext sc){
        // Query records here and update field
    }
}

OR

public class ScheduleApex implements schedulable {
        public void execute(SchedulableContext sc){
            // create instance of BatchApex and execute that
        }
    }

public class BatchApex implements 
    Database.Batchable<sObject>{

   public Database.QueryLocator start(Database.BatchableContext BC){
      // Return query for fetching required records
   }
    
   public void execute(
                Database.BatchableContext BC, 
                List<sObject> scope){
      // update field for above records
      }
   }
public void finish(Database.BatchableContext BC){
   }
}
4
  • In general, prefer the simplest solution that will work. How many records are you working with here? How fast is that number growing?
    – Derek F
    Commented Jul 11 at 13:17
  • Around 10,000 records. Since this is the sync limit, is it better to have batch apex?
    – coder123
    Commented Jul 11 at 13:18
  • 1
    Batch or Queueable Apex are the two main ways to break things into multiple transactions (i.e. multiple, independent sets of governor limits). 1,000 records should be perfectly manageable without resorting to either one of those (unless these records are towards the bottom of an SObject hierarchy that has a lot of triggers/flows that cause other triggers/flows to run). If that number isn't growing, or is growing slowly, then sticking with just the Schedulable is going to be faster to develop (and easier to test).
    – Derek F
    Commented Jul 11 at 13:29
  • 1
    You should also run your logic and look at the debug log to see how much of the main governor limits it consumes. That + the data growth rate would give you a good idea of when you'd need to revisit the code (and move to Schedulable + Batch/Queueable). That information would also make a compelling/meaningful code comment.
    – Derek F
    Commented Jul 11 at 13:32

1 Answer 1

3

Technically you could do it either way. Taking this into consideration, I would then analyze how you can scale this solution.

If you consider a scenario where the number of records easily exceeds the governor limits for both sync and smaller async transactions (such as a queueable), then the obvious choice is to go with the batch option (which is async, but is specifically made for update huge amounts of data).

So yes, do schedule a batch for it, even if it updates a small subset of records in the org, because then you'll likely not have to worry about performance and limits in the near future in case the number of records goes up.

1
  • Thankyou for the suggestion. You made some valid points.
    – coder123
    Commented Jul 11 at 13:26

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .