Apex Code Development You need to sign in to do that
Don't have an account?
craigmh Bulk Triggers and Picklist Describes
I've run into an issue with a trigger...it does a picklist describe on three separate fields, so each time it fires, it only has 3 describes. I've bulkified it so that this isn't done in a loop. The issue is that the trigger is limited by the batch size of 200 records. So if I insert 1000 records, the trigger runs 5 times, and 15 describes are performed. Since the picklist describe limit is 100, and it's for the entire DML operation, not just each batch, this means I can only run the trigger 33 times. At 200 records per batch, that's 6,600 records, which is definitely a good-sized chunk. But being able to insert 10,000 records at a time, I bump into the picklist describe limit first. I'm just wondering if there's a better methodology, other than storing the picklist values somewhere else, and referencing that instead of doing describes.
Am hoping that picklist values which are described once you want to use them again and again in different batch threads (chunks). I think you can do this by maintaining your batch state :
Now you can describe the picklist values in constructor and maintain them in variables of the batch class and then use them in different batch threads without describing them again and again. Hope am clear with my words.
Here is the example :
http://forceguru.blogspot.com/2011/03/how-to-send-more-than-10-e-mails.html
In code I am maintaining the state of Map (userCaseMap) and List (allCaseLoggedToday).
Thanks
Ankit Arora
Blog | Facebook | Blog Page
Thanks, I think that may be part of the solution, but not all of it.
The issue I have is that I need to store the picklist values in some context outside of the trigger, since it can be called up to 50 times. I did create a class to implement the Database.Batchable interface, but I'm not sure if I implemented it correctly. I'm calling it inside the trigger, but it has the same issue. This gets more complex with the fact that this validation occurs when the records are created on the sObject from any source. With how the sObject is used, records are very rarely created through the interface in SFDC. We will be loading them via the API, and when we do, it's not like we can keep the picklist describes stored in a way that we could if we were inserting via a controller class.
It shouldn't be that bad with the API, since that has a batch size of 200 as well, but whenever I run updates via the System Log, I run into this issue fairly often.