-
Notifications
You must be signed in to change notification settings - Fork 25
Description
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
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 the List<SObject> only contained Accounts.