GH-49078: [FS][Azure] Fix lossy pickling of SubTreeFileSystem(base_path, AzureFileSystem(...))#49140
Conversation
|
|
28ad544 to
d0a02e3
Compare
|
Sorry to be impatient, but please could someone review this? The test failure looks like a timeout, that I don't think is related. @AlenkaF please could you review? |
raulcd
left a comment
There was a problem hiding this comment.
Hi @Tom-Newton thanks for being patient. There are lots of PRs and issues being opened and sometimes it just takes a while to find the time. Just a really minor nit but the changes look reasonable to me.
012f6c5 to
648800f
Compare
This reverts commit 7cee1d0.
648800f to
9499abc
Compare
|
Rebasing on |
Thanks for reviewing 🙂 |
|
After merging your PR, Conbench analyzed the 3 benchmarking runs that have been run so far on merge-commit 0124d5b. There were no benchmark performance regressions. 🎉 The full Conbench report has more details. It also includes information about 44 possible false positives for unstable benchmarks that are known to sometimes produce them. |
Rationale for this change
Fix #49078
What changes are included in this PR?
AzureOptions, for the values that are currently stored only on the python side.ClearCredentials, so that it can't get into strange states by configuring one credential type then another. IMO configuring the credentials during initialisation on theAzureOptionswould be neater but I don't want to make this PR too big.AzureOptions::Equalsselfattributes and instead depend on getters from C++ side.Are these changes tested?
Equalsand newly added getter methods.pickle_with_and_without_subtree_filesystem, which can be used in place of thepickle_module. This adds test combinations with and without wrapping the filesystem in aSubTreeFilesystembefore pickling it.Are there any user-facing changes?
Only that pickling
SubTreeFileSystem(base_path, AzureFileSystem(...))now works properly.SubTreeFileSystem(base_path, AzureFileSystem(...))is lossy #49078