Apex Developer Previews and Betas

@Dominic Foster I've found a problem with the FormulaEval feature, and custom lookups. Is this a current limitation?

It works fine with standard lookups, but when trying to use custom lookups we get a GACK back.

To reproduce...

1. Create a custom lookup field on the Contact object to an Account, e.g. Other_Account__c.

2. Create a contact and populate both the Account (standard lookup) and Other_Account__c (custom lookup) with the same record.

3. Run the following apex code, changing the Id in the query to the contact id you just created.

Contact theContact = [SELECT Account.Name, Other_Account__r.Name FROM Contact WHERE Id ='003JX00000QMo5dYAD'];

FormulaEval.FormulaInstance formulaInstance = Formula.builder()

.withType(Contact.SObjectType)

.withFormula('Account.Name')

.withReturnType(FormulaEval.FormulaReturnType.STRING)

.build();

System.debug(formulaInstance.evaluate(theContact));

--- THIS WILL WORK FINE AND THE DEBUG WILL SHOW THE ACCOUNT NAME.

--- NOW CHANGE THE FORMULA TO Other_Account__r.Name FROM Account.Name

FormulaEval.FormulaInstance formulaInstance = Formula.builder()

.withType(Contact.SObjectType)

.withFormula('Other_Account__r.Name')

.withReturnType(FormulaEval.FormulaReturnType.STRING)

.build();

System.debug(formulaInstance.evaluate(theContact));

--- YOU NOW GET AN EXCEPTION IN THE LOGS

Error on line 23, column 1: System.UnexpectedException: Salesforce System Error: 250844729-248762 (162743969) (162743969)

(System Code)

Hi everyone, 

Today I've taken a look and tested the Apex Cursor's Beta on a Developer Pro Sandbox (Unlimited Edition), using a Cursor on a query that returned ~345,000 records, up to a point where I'm getting the following exception message: 

Cursor Rate Limiting Exception : DailyApexCursorRowsLimit Limit exceeded.

Question is, according to the Apex Governor Limits documentation, I have a 100 million limit on cursor daily rows I can fetch, can't tell for sure but I feel like it was less for me, 100M/345k = ~288 tests 

Is there a way to check for this limit? I tried using the limits API endpoint (/services/data/v63.0/limits) but it's not returned, also there is no method for this in the Limits class. 

Second question is, (can't tell right now, will check tomorrow), but if I remember correctly, is the  Limits.getFetchCallsOnApexCursor() working as expected? the few times I checked in the debug logs it was returning 0, even after fetching 10 times on the cursor for that transaction. 

And lastly, reading the Apex Cursors (Beta) documentation, says that Apex cursors have the same expiration limits as API Query cursors, that is, results are available for 2 days. Say you have a LWC that calls an Apex method in the connectedCallback(). This method creates a cursor for a query and returns a set of records (cursor.fetch(0, 200); for example). 

Since the query results are stored for 2 days, is it really mandatory to create the cursor each time the components is loaded? How would I access records from a non-expired cursor, if possible? 

Thanks for reading, hope my questions make sense :) 

CC: @Dominic Foster

@Dominic Foster, some questions regarding Database.Cursor:

Type safety

Why is Database.Cursor not templated? According to the material I've seen, I can declare and use a cursor like:

Database.Cursor contactCursor = Database.getCursor('SELECT Id FROM Contact');List<Contact> contacts = contactCursor.fetch(0, 200);

I would have expected to have needed to declare the cursor like:

Database.Cursor<Contact> contactCursor = ...;

If we don't have templating, what should happen if I do:

Database.Cursor contactCursor = Database.getCursor('SELECT Id FROM Contact');List<Account> accounts = contactCursor.fetch(0, 200);

Re-used cursors, user mode and sharing

Cursors can be passed around through Apex code, and are serializable to allow them to be retained between transactions.

1. If I get a cursor for a user mode query, what happens if that cursor is re-used in a transaction for a different user with different permissions?
2. If I get a cursor in a without sharing class then perform the fetch in a with sharing class, is sharing applied against the results?

Happy path cursor expiration

Cursors live for up to 48 hours from what I understand. If I'm caching the cursor, given the cursor's current beta API, I understand I have to catch exceptions against the cursor method(s) to detect that it has expired.

Handling exceptions in a "happy path" like this, where essentially I just want to know the cursor is expired, is something of an anti-pattern (I've mentioned this with other APIs added "recently" too). Can we please have a simple method that tells me that the cursor is valid for the duration of my transaction (and make sure that if the cursor could expire during the transaction it is either treated as already expired or that it is kept alive to the end of the transaction)?

Fetching the final partial scope/chunk

From the AMA session it seems that if you ask for too many records from a given offset, an exception is thrown.

Could we have a variant of fetch that doesn't throw an exception and instead simply returns as many records as are available?

Fetching when records have been deleted

According to the AMA session, if records have been deleted, the number of records returned for a given "chunk" can be fewer than requested (or even 0) simply because one or more of the records that would have been returned has been deleted.

Could we have a variant of fetch that tries to return the number of records requested, even if records had been deleted since the cursor was obtained? This actually aligns with the previous point where fetch will finally just return as many records as it can, up to the scope size, regardless of how many records have been deleted and whether the cursor's underlying results have been exhausted.

This suggests, too, that the cursor should be able to return the "next record offset" through another method that can be called after a fetch. A value of -1 can indicate that there are no further records. A non-negative value could still result in 0 records being returned if all the remaining records have been deleted, but that's OK.

At first, I was really excited about this feature because I often use formulas in my developments, such as in triggers to access parent records values. This way, I could avoid an extra query, for example, accessing the Account.Name in Case before insert. But now, trying out this new feature, I'm a bit disappointed because I'm getting null for this specific case.

trigger CaseTrigger on Case (before insert) {

    FormulaEval.FormulaInstance nameFormula = Formula.builder().withReturnType(FormulaEval.FormulareturnType.STRING).withType(Case.SObjectType).withFormula('Account.Name').build();

    for (Case cs : Trigger.New) {       

System.debug('Apex Formula: ' + nameFormula.evaluate(cs));

        System.debug('Formula: '+cs.Account_Name_Formula__c);

    }

}

Is it on the roadmap to cover this?