gaborkaszab commented on code in PR #14465:
URL: https://github.com/apache/iceberg/pull/14465#discussion_r2559016818
##########
core/src/main/java/org/apache/iceberg/rest/RESTSessionCatalog.java:
##########
@@ -1010,6 +1011,82 @@ private FileIO tableFileIO(
return newFileIO(context, fullConf, storageCredentials);
}
+ /**
+ * Create a new {@link RESTTableOperations} instance for simple table
operations.
+ *
+ * <p>This method can be overridden in subclasses to provide custom table
operations
+ * implementations.
+ *
+ * @param restClient the REST client to use for communicating with the
catalog server
+ * @param path the REST path for the table
+ * @param headers a supplier for additional HTTP headers to include in
requests
+ * @param fileIO the FileIO implementation for reading and writing table
metadata and data files
+ * @param current the current table metadata
+ * @param supportedEndpoints the set of supported REST endpoints
+ * @return a new RESTTableOperations instance
+ */
+ protected RESTTableOperations newTableOps(
Review Comment:
I'm just curious here: These are protected, so not part of any API or so.
This means that there are no guarantees the signature of these functions don't
change and any change here is not considered a breaking change. I don't think
revAPI checks would break if I add a couple of extra parameters and change the
types for some of the existing ones.
However, if you make your application so that it overrides these functions
it could break with every Iceberg version bump. Isn't this an issue at your end?
Update: Don't get me wrong, I'm not proposing to put this into an API in any
kind, because then it'd make it difficult to deal with any kind of changes on
this front, and also it's be too much visibility for a functionality that is
considered somewhat internal. I'm just curious if you considered this risk of
potential application breaks after bumping an Iceberg version.
--
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]
