In this post we will be covering some of the most overlooked yet powerful features in apex
FlexQueue Methods
We are all aware that asynchronous jobs are put into a queue and that the existing jobs in queue determines how quickly the last job can get executed. What if I told you that you could rearrange the jobs in the flex queue so that you could run your queueable, simpler class without having to wait for a batch class with a lot of batches to finish? We have a system-defined class called "FlexQueue" that provides us with the four methods shown below that assist in changing the order of the jobs.
- moveAfterJob(jobToMoveId, jobInQueueId)
- moveBeforeJob(jobToMoveId, jobInQueueId)
- moveJobToEnd(jobId)
- moveJobToFront(jobId)
Source :
Get count of records updated/deleted without a SOQL Query
Did you know that it is possible to obtain a list of the IDs of records that have been modified within a specific timeframe without using a SOQL query? The Database class and the getUpdated method may be used to do this. The nicest feature of this approach is that it does not count against the SOQL Governor Limits, allowing you to obtain the IDs of entries that have been modified during a certain time period. It's crucial to remember that you can only obtain the changed records' IDs; all other data are not retrievable. We also have a method called "getDeleted" for fetching the Id's of deleted records
Fix 101 SOQL Error in Test class with future method
When writing test methods in a test class, it's critical to keep governor limits in mind. We may utilise Test.startTest() and Test.stopTest() to assist avoid exceeding these constraints. However, even these methods aren't always sufficient to keep us from exceeding our limits, especially when dealing with the creation of a record that necessitates the creation of records in numerous other objects due to the dependency.(For example, creation of OpportunityLineItem involves creation of record in Account, Opportunity, Product2, PriceBook2, PriceBookEntry and then you can create record in Opportunity. Hitting 101 SOQL queries in a test class can be a real nightmare for developers).
In these scenarios, one way is to create a future method in the test class and move part of the logic from the test method to the newly creted future method. This technique will give us the benefit of availing asynchronous governor limits(200 SOQL per transaction), which are less stringent than synchronous governor limits with the added advantage that all asynchronous methods inside the test class will be running in the synchronous context.
Determine the source of Invocation of a method
Assume we have a method that is invoked from various places(say trigger, aura, VF Page etc.,) and we want to know the source of invocation or execute different logic based on how it is invoked. While methods such as Trigger.IsExecuting, System.isFuture(), and System.isBatch() can assist us in determining the source of invocation in some cases, there are some areas (such as anonymous blocks, Visualforce pages, and Aura) where we cannot.
In this instance, we may utilise the system-defined method "getQuiddity," which returns an enum indicating the source of the invocation. The available enum values may be found at the following link:
https://developer.salesforce.com/docs/atlas.en-us.apexref.meta/apexref/apex_enum_System_Quiddity.htm
By using the below line you will be able to determine the source of invocation
Quiddity quidSrc = Request.getCurrent().getQuiddity();
A working example is present in the below git
There are many other aspects that have yet to be addressed and will be discussed in future posts.
It is my sincere hope that you have acquired some new knowledge. Your feedback would be greatly appreciated.
No comments:
Post a Comment