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
In the LogsActivity trait's attributeValuesToBeLogged method, the comparison logic is currently hardcoded in a closure:
function ($new, $old) {
// Strict check for php's weird behaviorsif ($old === null || $new === null) {
return$new === $old ? 0 : 1;
}
// Handles Date interval comparisons since php cannot use spaceship// Operator to compare them and will throw ErrorException.if ($oldinstanceof DateInterval) {
return CarbonInterval::make($old)->equalTo($new) ? 0 : 1;
} elseif ($newinstanceof DateInterval) {
return CarbonInterval::make($new)->equalTo($old) ? 0 : 1;
}
return$new <=> $old;
}
The Issue: I encountered a case where an attribute's "old" value is an integer and the "new" value is an object (Value Object). For instance, a "Free Shipping" threshold that can be either a number of items (int) or a currency amount (Money object).
In this scenario, the spaceship operator or strict null checks aren't flexible enough and might lead to incorrect logging or ErrorExceptions.
The Proposal: It would be very convenient to have a way to override this comparison logic in the Model, similar to how tapActivity allows custom behavior. We could introduce a method like compareAttributes (or similar) that the trait would check for before falling back to the default closure.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
In the LogsActivity trait's
attributeValuesToBeLoggedmethod, the comparison logic is currently hardcoded in a closure:The Issue: I encountered a case where an attribute's "old" value is an integer and the "new" value is an object (Value Object). For instance, a "Free Shipping" threshold that can be either a number of items (int) or a currency amount (Money object).
In this scenario, the spaceship operator or strict null checks aren't flexible enough and might lead to incorrect logging or ErrorExceptions.
The Proposal: It would be very convenient to have a way to override this comparison logic in the Model, similar to how tapActivity allows custom behavior. We could introduce a method like compareAttributes (or similar) that the trait would check for before falling back to the default closure.
Beta Was this translation helpful? Give feedback.
All reactions