You Can’t Do That on Salesforce is a Twitch and YouTube stream where we build silly things that may or may not belong on the Salesforce platform for laughs and learning.
Who's running this thing?It's Tom Patros. When he's not streaming as Chief Troublemaker for YCDTOSF, he's the Founder & CTO at Red Argyle, a Salesforce consultancy. When he's not running Red Argyle, he's designing stuff and shooting photos.Tom started developing on Salesforce with S-Controls (yes, fricken S-Controls!). He's happy to see the platform has evolved since then.There's plenty of itches to stratch on the Salesforce platform, and Tom gets a kick out of sharing ideas and doing "stream-of-consciousness" architecture, design, and development for anyone curious enough to tune in.
Batch Apex Iterables: BYO Records
If you're like me, you probably return a QueryLocator in your Batch Apex start() method almost exclusively. After all, Batch Apex is meant to loop over records and do something with them or to them, right?While working on Inefficient Icon Inventory (III), the need arose to loop over records that didn't exist yet - specifically: the creation of Pixel records, which comprise an individual Icon.For a little background, here's how things work in III:1. User creates an Icon record. In doing so, User indicates the dimensions of said Icon in pixels. Let's say it's 256px x 256px for our example.2. This is YCDTOSF, so we make... interesting decisions about how to use the Salesforce platform. In the case of III, we create a record to represent each pixel in the Icon. Because why not. Also because it lets us do interesting things like store colors, fire platform events, and build collaborative pixel-editing UIs (check out the III playlist on Youtube)3. Math time: 256x256 = 65,536 pixels in our example Icon. If you know your DML rules, you know that's way too many records to insert in a single transaction. We need to spread them out, and Batch Apex is a great option for this.But wait: we don't have any Pixel records to loop over in the batch - what are we to do???As you likely guessed from the title: Iterables are here to help. Let's see this in action:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
We're returning Iterable<sObject> from the start() method, which allows you to return a List or Iterator of any object (or sObject in this example) of your choosing.Remember those Pixel records we want to create? The loops in the start() method are creating them by looping over the width and height of the Icon requested and initializing Pixel records in a List. That List gets returned, and the execute() method will receive them in batches of 200 (or whatever batch size you configure your Batch Apex to execute). In our case, we've already done the heavy lifting of initializing the records in the start()method, and now we just need execute() to insert them at a DML-friendly scale:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This approach worked great for III because the Icon knows what Pixel records are needed based on its dimensions, and it can lean on Batch Apex and Iterables to do the heavy lifting.I was a little concerned about creating a List<Pixel> with 65,536 items in it, but the batch didn't seem to bat an eye. I'd like to push that number much further, but to do so I'll need to test somewhere else besides a scratch org, where data storage is very limited. At 65K records, the batch was completing in about 3-5 minutes - not too shabby.While III is a very contrived app, maybe this approach will be useful to you in other ways.
