Muhammad-Ikhwan-Fathulloh opened a new pull request, #17857: URL: https://github.com/apache/iotdb/pull/17857
This PR fixes an issue in `LimitNode` where `tiesResolvingScheme` was not fully integrated into the node lifecycle. Previously, the field was ignored during serialization and deserialization, meaning its state could be lost when query plans were reconstructed. In addition, the deserialization logic passed `null` to an `Optional<OrderingScheme>` field, which could lead to potential `NullPointerException` issues. The field was also not included in `equals()` and `hashCode()`, resulting in incomplete object comparisons. ### Changes included * Added serialization and deserialization support for `tiesResolvingScheme`. * Replaced `null` assignments with proper `Optional.empty()` / `Optional.of(...)` handling to improve null safety. * Updated `equals()` and `hashCode()` to include `tiesResolvingScheme`. * Removed the outdated TODO comment since the field is now fully utilized. ### Impact This change helps ensure that: * Query plan state is preserved correctly during serialization and deserialization. * Potential `NullPointerException` risks are eliminated. * `LimitNode` comparisons accurately reflect the complete node state. * Planner behavior remains consistent and reliable when `tiesResolvingScheme` is present. ### Verification * Verified that serialization and deserialization follow the same field order. * Compared the implementation pattern with similar relational planner nodes such as `SortNode`. * Confirmed that `Optional<OrderingScheme>` is handled safely without using `null`. -- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. To unsubscribe, e-mail: [email protected] For queries about this service, please contact Infrastructure at: [email protected]
