wgtmac commented on code in PR #40329:
URL: https://github.com/apache/arrow/pull/40329#discussion_r1525713870
##########
cpp/src/parquet/encryption/crypto_factory.cc:
##########
@@ -172,8 +201,8 @@ std::shared_ptr<FileDecryptionProperties>
CryptoFactory::GetFileDecryptionProper
const KmsConnectionConfig& kms_connection_config,
const DecryptionConfiguration& decryption_config, const std::string&
file_path,
const std::shared_ptr<::arrow::fs::FileSystem>& file_system) {
- auto key_retriever = std::make_shared<FileKeyUnwrapper>(
- &key_toolkit_, kms_connection_config,
decryption_config.cache_lifetime_seconds,
+ auto key_retriever = std::make_shared<CryptoFactoryFileKeyRetriever>(
Review Comment:
> My use case is probably a bit non-standard as I'm trying to provide a .NET
binding to the encryption API without users having to deal with manual memory
management.
This is similar to the java binding via JNI where the lifetime management is
tricky. Usually we provide a `releaseXXX` native call for users to explicitly
release the resource managed by the native code. I'm not sure if you can do the
similar thing.
> This got me thinking, I wonder how pyarrow handles this. And it turns out
pyarrow has the same issue.
pyarrow users have access to the crypto_factory, so I don't think this is a
problem.
--
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]
