27

The upsert() DML operation requires a specific List based on a specific sObject type, for instance:List<Account> lstAccount = new List<Account>();

However, we are trying to generate a generic method which allows us to pass by an sObject list containing all data records to be upserted for a specific sObject. An insert() operation allows us to use a List<sObject> to be inserted but the upsert() function is rejecting it:

List<sObject> listWRecords = new List<sObject>();
listWRecords.add(new Foo__c(Name="Record1"));
listWRecords.add(new Foo__c(Name="Record2"));

upsert(listWRecords, 'ExternalIdFieldFrom_Foo__c', false);

Which will result in an error saying that the upsert must be performed on a concrete entity type.

Dynamically casting an sObject list is also not possible; I've seen solutions to 'hard code' or create Wrapper classes for each sObject on your org. But we would like to create a generic option here.

Another possibility would be to create some logic mimicking an upsert by splitting it into an update() and an insert() operation. Keeping in mind Salesforce limits, I do not see an option to go this way.

  • So yes we have same problem. We essentially have a metadata engine on top of the SFDC engine as we are a OEM/ISV. To do proper Apex SOC and Enterprise Design Patterns without additional overhead of creating our own UPSERT operation is frustrating. The fact we need to consume additional SOQL calls / governor limits, create additional unit test coverage scenarios, and other engineering effort is frustrating. – CoryCowgill May 6 '15 at 1:18
36

I know this approach is strange because you are still working with a List<SObject>, but when you assign it you can make it more specific (e.g. List<Account>) by using Type.forName and Type.newInstance methods.

public static void dynamicUpsert(List<SObject> records)
{
    Schema.SObjectType sObjectType = records.getSObjectType();
    if (sObjectType != null)
    {
        String listType = 'List<' + sObjectType + '>';
        List<SObject> castRecords = (List<SObject>)Type.forName(listType).newInstance();
        castRecords.addAll(records);
        upsert castRecords;
    }
}

The getSObjectType call may not be completely reliable, especially since some of these records are being inserted and hence won't have ids. For that reason, it is probably better to accept sObjectType as an additional parameter instead of trying to determine it on the fly.

public static void dynamicUpsert(List<SObject> records, SObjectType sObjectType)
{
    String listType = 'List<' + sObjectType + '>';
    List<SObject> castRecords = (List<SObject>)Type.forName(listType).newInstance();
    castRecords.addAll(records);
    upsert castRecords;
}

Update

Some bad news, as discovered here (actually earlier than your post), the above methodology does not always work. Specifically, if I want to perform a partial upsert and also specify an external Id field, I get a compile fail.

Database.upsert(castRecords, externalIdField); // compiles, throws TypeException
Database.upsert(castRecords, /*allOrNone*/ false); // compiles, throws TypeException
Database.upsert(castRecords, externalIdField, /*allOrNone*/ false); // compile fail 

Additional Update

I have a case open with support and it has been escalated to Tier 3. Currently the responses I'm getting are all along the lines of "will update you tomorrow," but I will post here if I get any resolution.

Additional Update

Support claims the three parameter signature failure is WAD. They said if I want them to actually fix it, I need to post on an Idea, so here it is, vote for it!

Tier 3 ... performed some testing and it looks like that we cannot do upsert with List regardless of which of the 3 method signatures you use.

The only difference in behavior seems to be that we block using the 3-arg one at compile time and the 2-arg and 0-arg ones fail at run- time.

Basically for the 3-arg we validate at compile time that you are not passing in a list parameterized with SObject. But for the other 2 we compile it and we allow it to run and check in the call whether the list is generic.

We could make the 3-arg work but it seems like a feature request and based on the behavior of the 0-arg and 2-arg versions we would presumably still enforce that the underlying list isn't generic.

  • Hi Adrian, thanks for the reply! We have finished our developments but, when I have some time available the coming days, I will definitely play around with your solution in our scope. I'll let you know the outcome. Thanks again! – Robin Wijnen Aug 19 '15 at 6:43
  • @RobinWijnen Did it work? – Fernando Gavinho Dec 7 '15 at 12:28
  • @FernandoGavinho I have successfully implemented this in a DML library and it does work. – Adrian Larson Dec 7 '15 at 18:05
  • very good work here..... – Eric Dec 8 '15 at 19:04
  • 1
    Thanks @AdrianLarson for talking to support! Voted for the idea – Robin Wijnen May 3 '16 at 9:01
4

Perhaps following this pattern will point you in the right direction.

In general, all type information is available at runtime. This means that Apex enables casting, that is, a data type of one class can be assigned to a data type of another class, but only if one class is a child of the other class. Use casting when you want to convert an object from one data type to another.

In the following example, CustomReport extends the class Report. Therefore, it is a child of that class. This means that you can use casting to assign objects with the parent data type (Report) to the objects of the child data type (CustomReport).

In the following code block, first, a custom report object is added to a list of report objects. After that, the custom report object is returned as a report object, then is cast back into a custom report object.

Public virtual class Report {

   Public class CustomReport extends Report {
   // Create a list of report objects 

      Report[] Reports = new Report[5];

   // Create a custom report object 

      CustomReport a = new CustomReport();

   // Because the custom report is a sub class of the Report class, 

   // you can add the custom report object a to the list of report objects 

      Reports.add(a);

   // The following is not legal, because the compiler does not know that what you are  

   // returning is a custom report. You must use cast to tell it that you know what 

   // type you are returning 

   // CustomReport c = Reports.get(0); 


   // Instead, get the first item in the list by casting it back to a custom report object 

      CustomReport c = (CustomReport) Reports.get(0);
   }
}
  • Hi crmprogdev, thanks for your fast reply! But I don't see a solution using the your suggested approach. Mainly because the type of sObject can be of any type. We are doing something in this way (objectName can be anything): List<sObject> recordsToUpsert = new List<sObject>(); sObjecType type = Schema.getGlobalDescribe().get(objectName); for(blablablbbla) { sObject importData = type.newsObject(); /** Do some stuff with importData **/ recordsToUpsert.add(importData); } So casting from sObject towards any sObjectType is not working (according to our understanding). – Robin Wijnen Feb 2 '15 at 15:05
  • All SF objects are children of sObjects. The issue might be that you're trying to cast a list of sObjects rather than a single record of the sObject like the class above does. That's the main thing I see about the code I posted. – crmprogdev Feb 2 '15 at 15:52
  • Thanks! You are correct that we tried to cast a list in stead of a single record. Problem is that a single record is not an option to perform DML operations upon. We do not want to have a DML inside a loop. Current solution has been build based upon mimicking the internal Upsert operation. – Robin Wijnen Feb 3 '15 at 7:50

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.