flink-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From GitBox <...@apache.org>
Subject [GitHub] [flink] bowenli86 commented on a change in pull request #8404: [FLINK-11476][table] Create CatalogManager to manage multiple catalogs
Date Tue, 21 May 2019 18:02:25 GMT
bowenli86 commented on a change in pull request #8404: [FLINK-11476][table] Create CatalogManager
to manage multiple catalogs
URL: https://github.com/apache/flink/pull/8404#discussion_r286154197
 
 

 ##########
 File path: flink-table/flink-table-api-java/src/main/java/org/apache/flink/table/api/TableEnvironment.java
 ##########
 @@ -280,6 +317,54 @@
 	 */
 	void sqlUpdate(String stmt, QueryConfig config);
 
+	/**
+	 * Gets the current default catalog name of the current session.
+	 *
+	 * @return The current default catalog name that is used for the path resolution.
+	 * @see TableEnvironment#useCatalog(String)
+	 */
+	String getCurrentCatalog();
+
+	/**
+	 * Sets the current catalog to the given value. It also sets the default
+	 * database to the catalog's default one. To assign both catalog and database explicitly
+	 * see {@link TableEnvironment#useDatabase(String, String)}.
+	 *
+	 * <p>This is used during the resolution of object paths. The default path is constructed
as
+	 * {@code [current-catalog].[current-database]}. During the resolution, first we try to
look for
+	 * {@code [default-path].[object-path]} if no object is found we assume the object path
is a fully
+	 * qualified one and we look under {@code [object-path]}.
+	 *
+	 * @param catalogName The name of the catalog to set as the current default catalog.
+	 * @throws CatalogException thrown if a catalog with given name could not be set as the
default one
+	 */
+	void useCatalog(String catalogName);
 
 Review comment:
   My comment can be a bit misunderstanding. Yeah, my point is we just need to be consistent
with how it's exposed. An example is that now, contrary to `useCatalog()`, `Catalog`'s APIs
not only document `CatalogException` in javadoc but also `throws CatalogException` in their
signatures.
   
   Seems that we all agree upon the javadoc part. What do you guys think of the signature
part? If we all feel it's not necessary to expose it to users in the API, I feel it's better
to remove `throws CatalogException` from `Catalog`'s API signatures to be consistent.

----------------------------------------------------------------
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:
users@infra.apache.org


With regards,
Apache Git Services

Mime
View raw message