jackye1995 commented on a change in pull request #2444: URL: https://github.com/apache/iceberg/pull/2444#discussion_r632881341
########## File path: api/src/main/java/org/apache/iceberg/encryption/TableMetadataEncryptionManager.java ########## @@ -0,0 +1,59 @@ +/* + * Licensed to the Apache Software Foundation (ASF) under one + * or more contributor license agreements. See the NOTICE file + * distributed with this work for additional information + * regarding copyright ownership. The ASF licenses this file + * to you under the Apache License, Version 2.0 (the + * "License"); you may not use this file except in compliance + * with the License. You may obtain a copy of the License at + * + * http://www.apache.org/licenses/LICENSE-2.0 + * + * Unless required by applicable law or agreed to in writing, + * software distributed under the License is distributed on an + * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY + * KIND, either express or implied. See the License for the + * specific language governing permissions and limitations + * under the License. + */ + +package org.apache.iceberg.encryption; + +import java.util.Map; +import org.apache.iceberg.io.InputFile; +import org.apache.iceberg.io.OutputFile; + +/** + * An encryption manager to handle top level table metadata file encryption. + * <p> + * Unlike other Iceberg metadata such as manifest list and manifest, + * because table metadata is the top level Iceberg metadata, + * we do not leverage any other file to store its encryption information. + * Therefore, this encryption manager assumes all encryption metadata are externally managed, + * and directly transforms the file to its encrypting or decrypting form. + */ +public interface TableMetadataEncryptionManager { Review comment: @rdblue thanks for the review, I finally got some time to pick this up. > why not use the existing encryption APIs and create the encryption manager in the catalog Yes that is another option to go, but by keeping everything in the encryption manager, the encryption manager has to be "partially" initialized so that it can only encrypt and decrypt table metadata files, and then be initialized again with table metadata to be able to encrypt and decrypt other files. Comparing with that experience, I think adding another manager seems to be cleaner, and also easier for users to extend for any custom need while still using the same encryption manager for other files. With that being said, I don't have a strong opinion on this, if we think it is important to keep everything in one place and allow having that partial initialization experience. I have updated this PR to include all the changes needed when going with the current approach, it should provide a better view of what is going on. -- 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. For queries about this service, please contact Infrastructure at: [email protected] --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
