Is your feature request related to a problem?
The first think I usually look for (when checking DML) is the object type and it often just says SObject (from the list type). We very rarely use mixed DML.
Describe the solution you'd like
Wow about parsing it from the trigger type if present?
0:00:00:000 CODE_UNIT_STARTED [EXTERNAL]|<anId>|ns.MyObjectTrigger on MyObject trigger event BeforeInsert|__sfdc_trigger/ns/MyObjectTrigger
Instead of showing DML Op:Insert Type:SObject we can parse from the CODE_UNIT_STARTED and show DML Op:Insert Type:MyObject
Sometimes we lack some SObject type info
1 issue is that we are not provided with either the namespace or whether the SObject is a standard or custom object.
e.g MyObject could be MyObject or MyObject__c or ns__MyObject__c we have no way of knowing.
mixed dml
If we have multiple CODE_UNIT_STARTED and therefore multiple SObject types for a single DML it would break the grouping. We should intead keep the dml being grouped on op and type:SObject and add additional context to show how many object types were included in the dml
Edit
not currently deliverable we need SF changes to log output, see this comment
Is your feature request related to a problem?
The first think I usually look for (when checking DML) is the object type and it often just says SObject (from the list type). We very rarely use mixed DML.
Describe the solution you'd like
Wow about parsing it from the trigger type if present?
Instead of showing
DML Op:Insert Type:SObjectwe can parse from the CODE_UNIT_STARTED and showDML Op:Insert Type:MyObjectSometimes we lack some SObject type info
1 issue is that we are not provided with either the namespace or whether the SObject is a standard or custom object.
e.g MyObject could be
MyObjectorMyObject__corns__MyObject__cwe have no way of knowing.mixed dml
If we have multiple
CODE_UNIT_STARTEDand therefore multiple SObject types for a single DML it would break the grouping. We should intead keep the dml being grouped on op and type:SObject and add additional context to show how many object types were included in the dmlEdit
not currently deliverable we need SF changes to log output, see this comment
Determining the SObject type from triggers is unreliable since you only get CODE_UNIT log lines if there is a trigger present on the object, meaning if we were inserting a
List<SObject>that had both Accounts and Opportunities, but we only had a trigger on Account, it would look like theList<SObject>only contained Accounts.