With Apex cursors, you can work with large query result sets while not actually returning the entire result set. Cursors will break up the processing of a SOQL query result into pieces that can be processed within the bounds of a single transaction. Query results can be traversed in parts, with the flexibility to navigate forward and back in the result set. Cursors are a more powerful alternative to batch Apex that can be used in a chain of queueable Apex jobs, addressing this way of batch Apex’s limitations.
How: A cursor is created when a SOQL query is executed on a Database.getCursor() or Database.getCursorWithBinds() call. When a Cursor.fetch(integer
position, integer count) method is invoked with an offset position and the count of records to fetch, the corresponding rows are returned from the
cursor. To get the number of cursor rows returned from the SOQL query, use Cursor.getNumRecords(). You must track the offsets or positions of the
results within your particular processing scenario
Exceptions: Apex cursors throw the following new system exceptions:
– System.FatalCursorException
– System.TransientCursorException, transactions that fail with System.TransientCursorException can be retried
Limits: Apex cursors have the same expiration limits as API Query cursors:
– Maximum number of rows per cursor: 50 million (both synchronous and asynchronous)
– Maximum number of fetch calls per transaction: 10 (both synchronous and asynchronous)
– Maximum number of rows per day (aggregate limit): 100 million
– Maximum number of rows per day (aggregate limit): 100 million
To get these limits, use these new methods in the Limits class:
– Limits.getApexCursorRows() and its upper bound Limits.getLimitApexCursorRows() method
– Limits.getFetchCallsOnApexCursor() and its upper bound Limits.getLimitFetchCallsOnApexCursor() method
