As we know that
list<Sobject> are collection type.
So basic question I do have why Set doesn't support DML operation ?
We can perform DML on
List<Sobject> but why not on
Salesforce Stack Exchange is a question and answer site for Salesforce administrators, implementation experts, developers and anybody in-between. It only takes a minute to sign up.Sign up to join this community
One reason may be that
Set<SObject> is a risky mechanism to use: equality is based on all the fields (so is expensive) and if fields are changed logic can easily break. Same problem using
SObject as a
Map key. So not a pattern to be encouraged.
But perhaps just because also supporting
Set<SObject> adds a bunch of extra methods that need documenting and supporting. (Given that there isn't any common superclass.) And the conversion to list is trivial:
Set<SObject> s = ...; someDmlOperation(new List<SObject>(s));
Sets (and Maps) cannot be cast to Sets of a different type. For example,
Set<sObject> t = (Set<sObject>)new Set<Contact>() will fail with the message
Incompatible types since an instance of Set<Contact> is never an instance of Set<SObject>. The database methods, and presumably DML keywords, are not implemented as generic methods, so they could only take a
Set<sObject>, not any concrete sObject type. That would be a radical departure from the behavior of the
List overloads, which can take either a
List<sObject> or e.g. a
List<Contact>, because lists are implicitly convertible from a contained type to a superclass of that contained type.
Most likely, the methods were not implemented as generics just because it would make the syntax awkward, since you would need something like
insert<Contact> new Set<Contact>(), or they would need to add special compiler logic to deduce the type of the passed object. The actual upside is pretty minor as well, as Keith C's answer explains, since
Set<sObject> can have behavior that is surprising to developers, and converting it to a list is relatively minor.
The values inside a set are supposed to be immutable; changing them means that values can be "lost" inside the object until the next time you debug the object, which seems to reset its internal state. In other words, it could introduce all kinds of subtle bugs, particularly on insert/upsert operations.