rdblue commented on code in PR #7913:
URL: https://github.com/apache/iceberg/pull/7913#discussion_r1414697348


##########
core/src/test/java/org/apache/iceberg/view/ViewCatalogTests.java:
##########
@@ -1534,4 +1535,90 @@ public void updateViewLocationConflict() {
         .isInstanceOf(NoSuchViewException.class)
         .hasMessageContaining("View does not exist: ns.view");
   }
+
+  @Test
+  public void concurrentReplaceViewVersion() {
+    TableIdentifier identifier = TableIdentifier.of("ns", "view");
+
+    if (requiresNamespaceCreate()) {
+      catalog().createNamespace(identifier.namespace());
+    }
+
+    assertThat(catalog().viewExists(identifier)).as("View should not 
exist").isFalse();
+
+    View view =
+        catalog()
+            .buildView(identifier)
+            .withSchema(SCHEMA)
+            .withDefaultNamespace(identifier.namespace())
+            .withQuery("trino", "select * from ns.tbl")
+            .create();
+
+    assertThat(catalog().viewExists(identifier)).as("View should 
exist").isTrue();
+
+    ReplaceViewVersion replaceViewVersion =
+        view.replaceVersion()
+            .withQuery("trino", "select count(*) from ns.tbl")
+            .withSchema(SCHEMA)
+            .withDefaultNamespace(identifier.namespace());
+
+    ReplaceViewVersion replaceViewVersionConcurrent =
+        view.replaceVersion()
+            .withQuery("spark", "select count(*) from ns.tbl")
+            .withSchema(OTHER_SCHEMA)
+            .withDefaultNamespace(identifier.namespace());

Review Comment:
   This doesn't actually simulate concurrent commits. This uses the same `view` 
instance and the `internalApply` method calls refresh. So what's actually 
happening is that the `ViewVersionReplace` is basing its changes on the correct 
metadata. That's why in the table version of similar tests, we actually load 
two separate instance of the table. That way the instance isn't up-to-date when 
the changes are created.
   
   In addition, because `internalApply` calls refresh, even if you were to use 
a separate `view` instance it will still update itself before creating the 
changes.
   
   I think to fix this, we should make the `internalApply` method 
package-private so that we can call it. Then to commit you can call the 
`ViewOperations` directly:
   
   ```java
     trinoView = catalog.loadView(identifier);
     ViewMetadata trinoUpdate = trinoView
         .replaceVersion()
         ...
         .internalApply();
   
     ViewOperations trinoOps = ((BaseView) trinoView).operations();
     trinoOps.commit(trinoOps.current(), trinoUpdate);
   ```
   
   That will exercise the server-side retry case, I think.



-- 
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-unsubscr...@iceberg.apache.org

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


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

Reply via email to