-
Notifications
You must be signed in to change notification settings - Fork 70
feat: sort field/order json serialize/deserialization #64
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
wgtmac
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Generally LGTM.
@lidavidm @zhjwpku @yingcai-cy WDYT?
97a2b14 to
4ab5529
Compare
| kDescending, | ||
| }; | ||
| /// \brief Get the relative sort direction name | ||
| ICEBERG_EXPORT constexpr std::string_view SortDirectionToString(SortDirection direction) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: we should probably only declare these functions here and put all implementation in the .cc file.
zhjwpku
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
| auto json_value = std::move(_tmp_##json_value.value()); | ||
| } // namespace | ||
|
|
||
| nlohmann::json ToJson(const SortField& sort_field) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was thinking about adding ToJson and FromJson member functions to each Spec classes, but your way might be better, users don't need to touch the json ser/der functions, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, there is no need to introduce json either.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, in this way we don't need to expose our internal json dependency.
| .message = "IdentityTransformFunction::Transform"}); | ||
| } | ||
|
|
||
| expected<std::unique_ptr<TransformFunction>, Error> TransformFunctionFromString( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related, but should we do something like define iceberg::Result<T> = expected<T, iceberg::Error>?
| } | ||
| } | ||
|
|
||
| #define TRY_ASSIGN(json_value, expr) \ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We'll probably want to make a broader version of this macro. (Not necessarily in this PR)
FWIW, you could steal the Arrow version, which uses a counter to autogenerate the name, so it can be used like ARROW_ASSIGN_OR_RAISE(auto value, ...) or ARROW_ASSIGN_OR_RAISE(foo.bar, ...) too
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Xuanwo
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thank you for working on this! There is no other concern from the community, I'm going to merge this one now.
|
Thank you @Xuanwo! |
No description provided.