[FLINK-36050][table] Support enhanced SHOW VIEW syntax#25200
[FLINK-36050][table] Support enhanced SHOW VIEW syntax#25200snuyanzin wants to merge 10 commits intoapache:masterfrom
SHOW VIEW syntax#25200Conversation
|
|
||
| public String[] fullDatabaseName() { | ||
| return Objects.isNull(this.databaseName) | ||
| ? new String[] {} |
There was a problem hiding this comment.
probably it's better to reuse lists rather than create arrays per call
|
|
||
| The syntax of sql pattern in `LIKE` clause is the same as that of `MySQL` dialect. | ||
| * `%` matches any number of characters, even zero characters, `\%` matches one `%` character. | ||
| * `_` matches exactly one character, `\_` matches one `_` character. |
There was a problem hiding this comment.
Do we want to provide examples? Or is it similar enough to SHOW TABLES that it'd be redundant?
There was a problem hiding this comment.
Or is it similar enough to SHOW TABLES that it'd be redundant?
yep, I had exactly this thought, may be we can explicitly say that SHOW TABLES examples could be also used as examples for SHOW VIEWS
There was a problem hiding this comment.
Yeah, maybe that is obvious? Not sure how pedantic to be in docs.
| final String prefix = notLike ? "NOT " : ""; | ||
| builder.append(String.format(" %sLIKE '%s'", prefix, likePattern)); | ||
| } | ||
| return "SHOW VIEWS"; |
There was a problem hiding this comment.
Ok, I think you want to return builder.build() instead of just SHOW VIEWS.
Is there a test that can be added to catch this?
There was a problem hiding this comment.
great catch, thanks
added extra tests covering this for both table and views
|
From a read through, just found the one issue and asked the one question. Overall, this looks good and is consistent with #18361 |
| Operation operation = parse(sql); | ||
| assertThat(operation).isInstanceOf(ShowViewsOperation.class); | ||
|
|
||
| ShowViewsOperation showTablesOperation = (ShowViewsOperation) operation; |
There was a problem hiding this comment.
Nice! I missed this typo... Very natural given that one should be using the other PR to make this one!
There was a problem hiding this comment.
There are several issues with the SHOW operations and a lot of duplicate code. I suggest to:
- In CatalogManager make:
public @Nullable String getCurrentDatabase() - In CatalogManager make:
public @Nullable String getCurrentCatalog() - In CatalogManaged implement:
public String qualifyCatalog(@Nullable String catalogName)throwing an error like inqualifyIdentifier. - In CatalogManager implement:
public String qualifyDatabase(String catalogName, @Nullable String databaseName). Throwing an error like inqualifyIdentifier.
Implement an AbstractShowOperation class covering Tables, Views, Procedures, (Models in the future)
Signed-off-by: snuyanzin <snuyanzin@gmail.com>
twalthr
left a comment
There was a problem hiding this comment.
Thank you @snuyanzin. This is a great refactoring! I left some last comments but in general the PR looks very good and is well tested.
...-table/flink-table-api-java/src/main/java/org/apache/flink/table/catalog/CatalogManager.java
Outdated
Show resolved
Hide resolved
...k-table-api-java/src/main/java/org/apache/flink/table/operations/ShowDatabasesOperation.java
Outdated
Show resolved
Hide resolved
| .getCatalogOrError(catalogManager.getCurrentCatalog()) | ||
| .listProcedures(catalogManager.getCurrentDatabase()); | ||
| return catalogManager | ||
| .getCatalogOrError(catalogManager.getCurrentCatalog()) |
There was a problem hiding this comment.
calls to getCurrentCatalog() and getCurrentDatabase() should not be required anymore?
There was a problem hiding this comment.
here it is a special case for these SHOW operations.
We have here preposition == null which means that we don't have IN or FROM in our SHOW query, so no catalog/database specified. In this case we assume that this SHOW operation should be done against current catalog/database
| CatalogManager catalogManager = context.getCatalogManager(); | ||
| String catalogName = | ||
| fullDatabaseName.size() == 1 | ||
| ? catalogManager.getCurrentCatalog() |
There was a problem hiding this comment.
here null could enter the flow again. and getOperation is not marked as @Nullable in parameters
There was a problem hiding this comment.
yep, depending on case catalog name and database name could be null, marked @Nullable in getOperation
example of such case
SHOW TABLEShere neither catalog nor database is specified and both will be null, then in Operation there will be getCurrentCatalog()/getCurrentDatabase() used
...rc/main/java/org/apache/flink/table/planner/operations/converters/SqlShowViewsConverter.java
Outdated
Show resolved
Hide resolved
| // it's to show current_catalog.current_database | ||
| return catalogManager | ||
| .getCatalogOrError(catalogManager.getCurrentCatalog()) | ||
| .getCatalogOrThrowException(catalogManager.getCurrentCatalog()) |
There was a problem hiding this comment.
there should be no call in this class to catalogManager.getCurrentCatalog(). Maybe I'm missing some context?
There was a problem hiding this comment.
here it is a case with preposition == null
i.e. when no catalog or database was specified e.g.
SHOW PROCEDURESin this case we need to use current catalog and database.
In theory we could precalculate it on converters level and then here use only catalogName, databaseName
There was a problem hiding this comment.
updated, now there is no getCurrentCatalog/getCurrentDatabase calls in operations
twalthr
left a comment
There was a problem hiding this comment.
Thank you @snuyanzin. Should be good in the next iteration.
...ain/java/org/apache/flink/table/planner/operations/converters/SqlShowFunctionsConverter.java
Outdated
Show resolved
Hide resolved
...ain/java/org/apache/flink/table/planner/operations/converters/SqlShowFunctionsConverter.java
Outdated
Show resolved
Hide resolved
twalthr
left a comment
There was a problem hiding this comment.
LGTM. Thanks for the refactoring!
What is the purpose of the change
Support enhanced
SHOW VIEWSsyntax likeSHOW VIEWS FROM catalog1.db1 LIKE 't%'in a way similar to existing
SHOW TABLESsyntaxBrief change log
parser was extended
Verifying this change
catalog_database.q in sql client and sql gateway
Does this pull request potentially affect one of the following parts:
@Public(Evolving): ( no)Documentation