+ Start a Discussion
jadentifyjadentify 

Dynamic SObject List Creation for Object that Cannot be Queried

I've seen a recommended practice of creating a dynamic SObject by running a query that returns 0 objects like sObject[] objects = [SELECT Id FROM Contact WHERE ID=NULL];

 

Is there another method of creating a concrete sObject list so it can be used in DML that does not involve querying? 

For example the FeedPost object is no queriable so this method cannot be used. I cannot create individual object feed lists either since i will be creating many different objects posts (at least 5) and this will cause me to go over the governor limits

Best Answer chosen by Admin (Salesforce Developers) 
rh1212rh1212

To use a non-concrete sobject list in DML you just need to upgrade your APEX class version to 19 or 20 and you'll be all set. so you can do 

 

 

sObject[] posts = new sObject[]{};
insert posts;

 

 

All Answers

mikefmikef

I am not exactly sure what you want to do but this works just fine.

 

 

sObject fp = new FeedPost();

 

jadentifyjadentify

It has to be dyanmic. using the object name is static. The whole reason is because we have a managed package that will have a Chatter integration. But the app needs to function in Chatter disabled orgs. This situation requires you to use Dyanmic APEX for all Chatter objects. Therefore sObject[] objects = new FeedPost[]{} will not work

mikefmikef

After your global describe call you could test if the org is chatter enabled and if it is then go into calling the feedpost code.

jadentifyjadentify

you cannot do that as you cannot install a managed package containing a Chatter component if chatter is disabled in the installing org. You have to use dynamic APEX. 

 

So back to the original question does anyone know who to dynamically create a concrete SObject[] list of FeedPost's that can be used in DML operations?

ca_peterson_againca_peterson_again

You can actually reference chatter objects in a chatter disabled org on one condition: that code is never executed. I'm using this trick, and it works as long as chatter is on in your dev org when you save the apex.

 

Further caveat: you can't use apex:outputField in visualforce for chatter fields if you do this.

 

I have a Chatter class, that I can't share all of sadly, but the constructor runs this code, you can guess at what the refresh() method does:

 

boolean this.chatterEnabled = true;
if(subject.getSObjectType().getDescribe().isFeedEnabled()){
            try{
                this.refresh();
            }catch(System.QueryException e){
                this.chatterEnabled = false; //we failed anyways for some reason
            }
        } else {
            this.chatterEnabled = false; //chatter is NOT supported on this object!
        }

 I use Chatter.cls for all feed management, and everything tests chatterEnabled before touching chatter-releated objects.

 

Yes, it's a ugly hack, but it works reliably for me, including wrapping all my chatter-releated test code in if(chatterEnabled) as salesforce only checks coverage in the publishing org.

 

If you don't want to go that route you can use the same trick:

 

List<sObject> myList;
Map<String, Schema.SObjectType> globalDescribe = Schema.getGlobalDescribe();
if(globalDescribe.containsKey('FeedPost'){
myList = new List<FeedPost>();
}

and it should work, as the code would never execute if there was no FeedPost object in the org.  

 

 

jadentifyjadentify

You are required to enable chatter if you managed package contains static references to chatter objects. 

 

I have tried this before and you can see the screen shot, sfdc will force the installing org to enable chatter to install the managed app. Any other suggestions?  Unless there is some special way to get around this

 

 

rh1212rh1212

To use a non-concrete sobject list in DML you just need to upgrade your APEX class version to 19 or 20 and you'll be all set. so you can do 

 

 

sObject[] posts = new sObject[]{};
insert posts;

 

 

This was selected as the best answer