Before, when using a value mapper with the mapper ‘List: Get Values’, it would work whether or not the target was an object. But since the newest update, you get this error when trying this on an empty string:
array_values(): Argument #1 ($array) must be of type array, string given
The error isn’t illogical, but this mapper always used to work whether there was data in there or not (value mappers generally even work when the pattern doesn’t exist at all).
I’m not sure what the ‘philosophy’ is regarding errors like this, but I generally liked that it simply worked even if the key doesn’t exist or the value is not appropriate. Otherwise, you’d need to start escaping everything, which is just annoying.
As part of our ongoing efforts to enhance system performance and security, we recently upgraded our system to utilize PHP 8.0, a significant update that brings several improvements. However, this upgrade has also introduced changes in behavior that have impacted certain functionalities.
After a thorough investigation, we have determined that the issue you experienced is directly related to this upgrade.
What is your philosophy on this? I don’t necessarily care, but because Alumio has basically always allowed stuff like Array Merges, value mappers etc, without giving back errors when the types are wrong, we’ve built it with that in mind.
Is this something you are going to return to old functionality, or should we start using these mappers more like JMESPath (strict typing)?
I’m not really searching for a workaround, because I’ve already worked around it.
However, we currently have dozens of instances where we used these transformers, and after this last update they might start failing. I’m asking whether you plan to fix this in a future upgrade, or whether we should expect this to be the default behaviour going forward.
Thank you for your confirmation.
As we explained previously, this is the impact of updating the PHP version; we can say that this will become a default behavior that cannot be avoided.