Open vibhatha opened 10 months ago
The original source likely ordered the functions in alphabetical order and the Java code is likely ordering based on the order that the functions were discovered.
Also I did check, the io.substrait.plan.Plan
of corresponding plans would yields to false
when we use the equals
method.
@EpsilonPrime seems like it. Would you recommend that this needs fixing?
One way to address this would be to implement a "normalize plan" method. It could sort the functions in place, populate a map with the old and new values, and then walk the protobuf replacing function references with the updated value. It could also do other normalization. I have something like that in substrait-cpp:
There's nothing in the spec that constrains that extensions need to be ordered in a specific way. I'm hesitant to officially encode any behaviour or expectations of ordering. That's not to say we can't provide a utility to normalize plans, it just wouldn't be based on anything in the spec.
Also I did check, the io.substrait.plan.Plan of corresponding plans would yields to false when we use the equals method.
If we consider these plans to be equal, this would be a good argument for a smarter equals method.
@vbarua I agree with the standard, this was a mere observation. I think for this case what we should provide is a smarter equals method. Do you think this would be a good feature to be added to a future release?
I think a smarter equality comparison would be a good approach.
I wrote a test case to evaluate the following and once we do the roundrip we don't get the same plan. I observed the diff and seems like the order of
extension_uris
comes in the opposite orderINPUT
OUTPUT
I don't think this would do any harm execution wise, but one would expect it to be similar in property order.