You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Jun 3, 2024. It is now read-only.
I've had a few versions of a class called SObjectComparator (or SObjectComparable or something similar) over the years - the goal of this class is to pass in two versions of the same record and provide methods to check what fields have changed (if any). This would be helpful to have in Nebula for validating records in a trigger (#79), determining if a record is dirty and needs to be saved, etc.
Ideally, this works best in a trigger context - triggers have all fields populated on an sobject during a trigger, making it easy to compare the before & after values of every field. If SObjectComparator is used during a non-trigger context, then there is a greater chance that the sobjects do not match simply because they do not have the same fields populated in memory. Some additional checks need to be added to check for this - sobject.getPopulatedFieldsAsMap() had a bug until recently where not all populated fields were returned, but one of the most recent SF releases has fixed it, so it should be usable now.
The text was updated successfully, but these errors were encountered:
I've had a few versions of a class called SObjectComparator (or SObjectComparable or something similar) over the years - the goal of this class is to pass in two versions of the same record and provide methods to check what fields have changed (if any). This would be helpful to have in Nebula for validating records in a trigger (#79), determining if a record is dirty and needs to be saved, etc.
Ideally, this works best in a trigger context - triggers have all fields populated on an sobject during a trigger, making it easy to compare the before & after values of every field. If SObjectComparator is used during a non-trigger context, then there is a greater chance that the sobjects do not match simply because they do not have the same fields populated in memory. Some additional checks need to be added to check for this - sobject.getPopulatedFieldsAsMap() had a bug until recently where not all populated fields were returned, but one of the most recent SF releases has fixed it, so it should be usable now.
The text was updated successfully, but these errors were encountered: