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
The ComparisonReport for non-equivalent structs is tricky because structs can have duplicate field names. As such, you can't determine non-equivalence without testing all of the values in the target struct. That means there isn't really a single event in the target struct that can be pointed to as the rhs in a ComparisonReport.
In the ion-c implementation, the lhs will be the field in the source struct that did not have a match in the target struct, and the rhs will always be the CONTAINER_END event of the target struct. This is nice because it at least shows which field in the source did not have a match in the target, but this information could alternatively be conveyed in the message.
Other implementations may not be structured in a way that makes it as easy to identify the exact field in the source struct that didn't match in the destination struct. ion-java, for example, has an Equivalence utility that simply returns a boolean. Being able to use this utility will make the ion-java CLI implementation much simpler, but will not allow for the non-matched field to be pinpointed.
I propose that for non-equivalent structs, the ion-test-driver spec should require that the lhs and rhs events in ComparisonReports of non-equivalent structs always be the CONTAINER_START events for those structs. If possible, implementations may put any additional information in the message to help humans narrow down the source of the comparison failure.
The text was updated successfully, but these errors were encountered:
The ComparisonReport for non-equivalent structs is tricky because structs can have duplicate field names. As such, you can't determine non-equivalence without testing all of the values in the target struct. That means there isn't really a single event in the target struct that can be pointed to as the
rhs
in a ComparisonReport.In the ion-c implementation, the
lhs
will be the field in the source struct that did not have a match in the target struct, and therhs
will always be theCONTAINER_END
event of the target struct. This is nice because it at least shows which field in the source did not have a match in the target, but this information could alternatively be conveyed in the message.Other implementations may not be structured in a way that makes it as easy to identify the exact field in the source struct that didn't match in the destination struct. ion-java, for example, has an
Equivalence
utility that simply returns a boolean. Being able to use this utility will make the ion-java CLI implementation much simpler, but will not allow for the non-matched field to be pinpointed.I propose that for non-equivalent structs, the ion-test-driver spec should require that the
lhs
andrhs
events in ComparisonReports of non-equivalent structs always be theCONTAINER_START
events for those structs. If possible, implementations may put any additional information in the message to help humans narrow down the source of the comparison failure.The text was updated successfully, but these errors were encountered: