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
GH-39865: [C++] Strip extension metadata when importing a registered extension #39866
GH-39865: [C++] Strip extension metadata when importing a registered extension #39866
Conversation
99c451e
to
3c3033d
Compare
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.
Mostly LGTM, just one nit
@@ -188,7 +186,7 @@ std::vector<std::pair<std::string, std::string>> KeyValueMetadata::sorted_pairs( | |||
return pairs; | |||
} | |||
|
|||
int KeyValueMetadata::FindKey(const std::string& key) const { | |||
int KeyValueMetadata::FindKey(std::string_view key) const { |
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.
👍
3c3033d
to
7d025df
Compare
CI failures are unrelated, will merge. |
After merging your PR, Conbench analyzed the 5 benchmarking runs that have been run so far on merge-commit 56951fe. There were 2 benchmark results indicating a performance regression:
The full Conbench report has more details. It also includes information about 5 possible false positives for unstable benchmarks that are known to sometimes produce them. |
…tered extension (apache#39866) ### Rationale for this change When importing an extension type from the C Data Interface and the extension type is registered, we would still leave the extension-related metadata on the storage type. ### What changes are included in this PR? Strip extension-related metadata on the storage type if we succeed in recreating the extension type. This matches the behavior of the IPC layer and allows for more exact roundtripping. ### Are these changes tested? Yes. ### Are there any user-facing changes? No, unless people mistakingly rely on the presence of said metadata. * Closes: apache#39865 Authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
…extension (#39866) ### Rationale for this change When importing an extension type from the C Data Interface and the extension type is registered, we would still leave the extension-related metadata on the storage type. ### What changes are included in this PR? Strip extension-related metadata on the storage type if we succeed in recreating the extension type. This matches the behavior of the IPC layer and allows for more exact roundtripping. ### Are these changes tested? Yes. ### Are there any user-facing changes? No, unless people mistakingly rely on the presence of said metadata. * Closes: #39865 Authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
…tered extension (apache#39866) ### Rationale for this change When importing an extension type from the C Data Interface and the extension type is registered, we would still leave the extension-related metadata on the storage type. ### What changes are included in this PR? Strip extension-related metadata on the storage type if we succeed in recreating the extension type. This matches the behavior of the IPC layer and allows for more exact roundtripping. ### Are these changes tested? Yes. ### Are there any user-facing changes? No, unless people mistakingly rely on the presence of said metadata. * Closes: apache#39865 Authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
…tered extension (apache#39866) ### Rationale for this change When importing an extension type from the C Data Interface and the extension type is registered, we would still leave the extension-related metadata on the storage type. ### What changes are included in this PR? Strip extension-related metadata on the storage type if we succeed in recreating the extension type. This matches the behavior of the IPC layer and allows for more exact roundtripping. ### Are these changes tested? Yes. ### Are there any user-facing changes? No, unless people mistakingly rely on the presence of said metadata. * Closes: apache#39865 Authored-by: Antoine Pitrou <antoine@python.org> Signed-off-by: Antoine Pitrou <antoine@python.org>
Rationale for this change
When importing an extension type from the C Data Interface and the extension type is registered, we would still leave the extension-related metadata on the storage type.
What changes are included in this PR?
Strip extension-related metadata on the storage type if we succeed in recreating the extension type.
This matches the behavior of the IPC layer and allows for more exact roundtripping.
Are these changes tested?
Yes.
Are there any user-facing changes?
No, unless people mistakingly rely on the presence of said metadata.