Skip to content

[FLINK-36050][table] Support enhanced SHOW VIEW syntax#25200

Closed
snuyanzin wants to merge 10 commits intoapache:masterfrom
snuyanzin:flink36050
Closed

[FLINK-36050][table] Support enhanced SHOW VIEW syntax#25200
snuyanzin wants to merge 10 commits intoapache:masterfrom
snuyanzin:flink36050

Conversation

@snuyanzin
Copy link
Contributor

What is the purpose of the change

Support enhanced SHOW VIEWS syntax like SHOW VIEWS FROM catalog1.db1 LIKE 't%'

in a way similar to existing SHOW TABLES syntax

Brief change log

parser was extended

Verifying this change

catalog_database.q in sql client and sql gateway

  • a number of unit tests

Does this pull request potentially affect one of the following parts:

  • Dependencies (does it add or upgrade a dependency): ( no)
  • The public API, i.e., is any changed class annotated with @Public(Evolving): ( no)
  • The serializers: (no)
  • The runtime per-record code paths (performance sensitive): ( no)
  • Anything that affects deployment or recovery: JobManager (and its components), Checkpointing, Kubernetes/Yarn, ZooKeeper: ( no)
  • The S3 file system connector: (yes)

Documentation

  • Does this pull request introduce a new feature? (yes )
  • If yes, how is the feature documented? (docs )

@flinkbot
Copy link
Collaborator

flinkbot commented Aug 14, 2024

CI report:

Bot commands The @flinkbot bot supports the following commands:
  • @flinkbot run azure re-run the last Azure build


public String[] fullDatabaseName() {
return Objects.isNull(this.databaseName)
? new String[] {}
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Do we want to provide examples? Or is it similar enough to SHOW TABLES that it'd be redundant?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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";
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

great catch, thanks

added extra tests covering this for both table and views

@jnh5y
Copy link
Contributor

jnh5y commented Aug 14, 2024

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;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice! I missed this typo... Very natural given that one should be using the other PR to make this one!

Copy link
Contributor

@jnh5y jnh5y left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

Copy link
Contributor

@twalthr twalthr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 in qualifyIdentifier.
  • In CatalogManager implement: public String qualifyDatabase(String catalogName, @Nullable String databaseName). Throwing an error like in qualifyIdentifier.

Implement an AbstractShowOperation class covering Tables, Views, Procedures, (Models in the future)

Signed-off-by: snuyanzin <snuyanzin@gmail.com>
Copy link
Contributor

@twalthr twalthr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

.getCatalogOrError(catalogManager.getCurrentCatalog())
.listProcedures(catalogManager.getCurrentDatabase());
return catalogManager
.getCatalogOrError(catalogManager.getCurrentCatalog())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

calls to getCurrentCatalog() and getCurrentDatabase() should not be required anymore?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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()
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here null could enter the flow again. and getOperation is not marked as @Nullable in parameters

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

yep, depending on case catalog name and database name could be null, marked @Nullable in getOperation

example of such case

SHOW TABLES

here neither catalog nor database is specified and both will be null, then in Operation there will be getCurrentCatalog()/getCurrentDatabase() used

// it's to show current_catalog.current_database
return catalogManager
.getCatalogOrError(catalogManager.getCurrentCatalog())
.getCatalogOrThrowException(catalogManager.getCurrentCatalog())
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

there should be no call in this class to catalogManager.getCurrentCatalog(). Maybe I'm missing some context?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

here it is a case with preposition == null
i.e. when no catalog or database was specified e.g.

SHOW PROCEDURES

in 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

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

updated, now there is no getCurrentCatalog/getCurrentDatabase calls in operations

Copy link
Contributor

@twalthr twalthr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thank you @snuyanzin. Should be good in the next iteration.

Copy link
Contributor

@twalthr twalthr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM. Thanks for the refactoring!

@snuyanzin snuyanzin closed this in 36347e5 Aug 20, 2024
@snuyanzin snuyanzin deleted the flink36050 branch July 29, 2025 08:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

4 participants