[GitHub] [iceberg] kbendick commented on a diff in pull request #4011: Allow table defaults to be configured and/ or enforced at catalog level using catalog properties.

[GitBox <gi...@apache.org>]

kbendick commented on code in PR #4011:
URL: https://github.com/apache/iceberg/pull/4011#discussion_r873988760


##########
aws/src/integration/java/org/apache/iceberg/aws/glue/TestGlueCatalogTable.java:
##########
@@ -368,4 +369,54 @@ public void testColumnCommentsAndParameters() {
     );
     Assert.assertEquals("Columns do not match", expectedColumns, actualColumns);
   }
+
+  @Test
+  public void testTablePropsDefinedAtCatalogLevel() {
+    String namespace = createNamespace();
+    String tableName = getRandomName();
+    TableIdentifier tableIdent = TableIdentifier.of(namespace, tableName);
+    ImmutableMap<String, String> catalogProps = ImmutableMap.of(
+        "table-default.key1", "catalog-default-key1",
+        "table-default.key2", "catalog-default-key2",
+        "table-default.key3", "catalog-default-key3",
+        "table-override.key3", "catalog-override-key3",
+        "table-override.key4", "catalog-override-key4",
+        "warehouse", "s3://" + testBucketName + "/" + testPathPrefix);
+
+    glueCatalog.initialize("glue", catalogProps);
+
+    Schema schema = new Schema(
+        NestedField.required(3, "id", Types.IntegerType.get(), "unique ID"),
+        NestedField.required(4, "data", Types.StringType.get())
+    );
+
+    org.apache.iceberg.Table table = glueCatalog.buildTable(tableIdent, schema)
+        .withProperty("key2", "table-key2")
+        .withProperty("key3", "table-key3")
+        .withProperty("key5", "table-key5")
+        .create();
+
+    Assert.assertEquals(
+        "Table defaults set for the catalog must be added to the table properties.",
+        "catalog-default-key1",
+        table.properties().get("key1"));
+    Assert.assertEquals(
+        "Table property must override table default properties set at catalog level.",
+        "table-key2",
+        table.properties().get("key2"));
+    Assert.assertEquals(
+        "Table property override set at catalog level must override table default" +
+            " properties set at catalog level and table property specified.",
+        "catalog-override-key3",
+        table.properties().get("key3"));
+    Assert.assertEquals(
+        "Table override not in table props or defaults should be added to table properties",
+        "catalog-override-key4",
+        table.properties().get("key4"));
+    Assert.assertEquals(
+        "Table properties without any catalog level default or override should be added to table" +
+            " properties.",
+        "table-key5",
+        table.properties().get("key5"));
+  }

Review Comment:
   I personally really don't like working with mocks, so I understand what you mean. I would consider adding some test that does get run through the CI test suite, to ensure that any changes that are made in the API are made against the Glue catalog (outside of compiler related errors).
   
   As it is true that the AWS integration tests aren't run on any schedule within the open source community (that I'm aware of) due to lack of infra.
   
   That said, I wouldn't consider it a hard requirement given that HadoopCatalog and HiveCatalog both have tests. Maybe adding GlueCatalog to the existing CatalogTests suite would be beneficial in the long run? Something to consider.



-- 
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: issues-unsubscribe@iceberg.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscribe@iceberg.apache.org
For additional commands, e-mail: issues-help@iceberg.apache.org