singhpk234 commented on code in PR #13225:
URL: https://github.com/apache/iceberg/pull/13225#discussion_r2485341114
##########
core/src/main/java/org/apache/iceberg/rest/RESTTableOperations.java:
##########
@@ -166,7 +208,67 @@ public void commit(TableMetadata base, TableMetadata
metadata) {
@Override
public FileIO io() {
- return io;
+ if (encryptionKeyId == null) {
+ return io;
+ }
+
+ if (encryptingFileIO == null) {
+ encryptingFileIO = EncryptingFileIO.combine(io, encryption());
+ }
+
+ return encryptingFileIO;
+ }
+
+ @Override
+ public EncryptionManager encryption() {
+ if (encryptionManager != null) {
+ return encryptionManager;
+ }
+
+ if (encryptionKeyId != null) {
+ if (kmsClient == null) {
+ throw new RuntimeException(
+ "Cant create encryption manager, because key management client is
not set");
+ }
+
+ Map<String, String> tableProperties = Maps.newHashMap();
+ tableProperties.put(TableProperties.ENCRYPTION_TABLE_KEY,
encryptionKeyId);
+ tableProperties.put(
+ TableProperties.ENCRYPTION_DEK_LENGTH,
String.valueOf(encryptionDekLength));
+ encryptionManager =
+ EncryptionUtil.createEncryptionManager(
+ encryptedKeysFromMetadata, tableProperties, kmsClient);
+ } else {
+ return PlaintextEncryptionManager.instance();
+ }
+
+ return encryptionManager;
+ }
+
+ private void encryptionPropsFromMetadata(TableMetadata metadata) {
Review Comment:
> I'm curious how these implementations handle the metadata-location field,
Most of the implementations that i am aware of are maintaining an in-memory
copy of what the catalog wrote to the object store, some what like a
**_write-through_** cache as the object store reads are expensive.
But IMHO no one stops the user to actually store the `metadata.json` in a db
(without persisting in object store) and play along with the virtual values as
most of the readers play read the LoadTableResponse#metadata() and ignore this
field as its a redundant call, this will particular become a problem when the
reader wants the actual metadata.json to use in something like `register_table`
call.
My understanding is we stored the keys info in HiveCatalog impl in the
metadata.json as part of table properties which means its a defined property
per iceberg table spec irrespective of what catalog one use, so imho we should
ideally use the same for REST
--
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]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
