Add support for SHOW (DATABASES|VITESS_SHARDS|VITESS_TABLETS) LIKE

[ajm188]

This addresses #6315 and then some.

Part 1

This PR updates the sql parser to add 4 new non-reserved keywords: KEYSPACES, VITESS_KEYSPACES, VITESS_SHARDS, and VITESS_TABLETS.

Then, we update the grammar to allow for an optional LIKE clause to be included when doing a SHOW DATABASES/KEYSPACES/VITESS_KEYSPACES (this is the entirety of #6315, the rest is additional things which I can file a separate issue for).

For filtering keyspaces, we create a regexp out of the LIKE clause, defaulting to .*, and only include keyspaces which match the regex.

Part 2 - filtering shards and tablets

Next, this PR updates the grammar again, to create a vitess_topo nonterminal, which can be one of the VITESS_SHARDS / VITESS_TABLETS terminals. For both of these cases, we allow an option like or where. The LIKE clause currently has the following behavior:

• for VITESS_SHARDS, match the regexp against "$keyspace/$shard"
• for VITESS_TABLETS, match the regexp against the tablet hostname

The where clause is currently unused, but in a future change I would like to add support for queries like: SHOW VITESS_TABLETS WHERE keyspace = "mykeyspace" AND tablet_type != "MASTER" (I have another branch with this, but the diff is quite large and I need to polish that quite a bit more).

Tests

Used 101_initial_cluster.sh for all testing 😅 😬

Results

mysql> show databases;
+-----------+
| Databases |
+-----------+
| commerce  |
+-----------+
1 row in set (0.00 sec)
mysql> show databases like '%commer%';
+-----------+
| Databases |
+-----------+
| commerce  |
+-----------+
1 row in set (0.00 sec)
mysql> show databases like '%non%';
Empty set (0.01 sec)
mysql> show databases like '%comm';
Empty set (0.00 sec)
mysql> show keyspaces like '%comm';
Empty set (0.00 sec)
mysql> show vitess_shards like 'commerce%'
    -> ;
+------------+
| Shards     |
+------------+
| commerce/0 |
+------------+
1 row in set (0.00 sec)
mysql> show vitess_shards like 'commerce';
Empty set (0.00 sec)
mysql> show vitess_tablets like '%notmylaptop%';
Empty set (0.00 sec)

mysql> show vitess_tablets like '%firelink%';
+-------+----------+-------+------------+---------+------------------+----------------+----------------------+
| Cell  | Keyspace | Shard | TabletType | State   | Alias            | Hostname       | MasterTermStartTime  |
+-------+----------+-------+------------+---------+------------------+----------------+----------------------+
| zone1 | commerce | 0     | MASTER     | SERVING | zone1-0000000100 | firelink       | 2020-09-19T21:23:23Z |
| zone1 | commerce | 0     | REPLICA    | SERVING | zone1-0000000101 | firelink       |                      |
| zone1 | commerce | 0     | RDONLY     | SERVING | zone1-0000000102 | firelink       |                      |
+-------+----------+-------+------------+---------+------------------+----------------+----------------------+
3 rows in set (0.00 sec)

Some questions I have:

• Is there a recommended way to test this behavior? Should I just add some cases to parse_test to show that the where/like clauses are getting parsed? Or is there a better place to test this logic?
• What is the policy around log lines? I left in some log lines to help me during development of this, but if there are places where you think logging would be helpful (or if you'd prefer I just delete all the log lines) please let me know!

[deepthi]

I'll let @systay comment on parser tests, but there are existing tests for show vitess_tablets which you could mimic and extend to test the query results.

[deepthi]

ping @systay

[deepthi]

What is the policy around log lines? I left in some log lines to help me during development of this, but if there are places where you think logging would be helpful (or if you'd prefer I just delete all the log lines) please let me know!

In this case, it is better to delete most of the logging you added for debugging (except maybe keep the warning while ignoring a where clause). In the general case we want enough log to diagnose issues, but not so much that log files fill up too quickly. It's a difficult balancing act and we pretty much have to refine the logging on an ongoing basis.

[deepthi]

👍

[deepthi]

use sqlparser.KeywordString here too?

[deepthi]

and here

[deepthi]

could you use utils.MustMatch instead of DeepEqual?

[ajm188]

Yep! (One day, I promise, I'll remember the first time 😅)

[ajm188]

@deepthi I noticed the rest of the assertions in this test case use reflect.DeepEqual, do you want me to go ahead update those too?

[deepthi]

that will be great!

[ajm188]

Done! If that makes the diff a little gross to review both sets of changes at once let me know and I'll happily split them up :)

[ajm188]

@systay finally got to pull in those changes, works great. Thanks again for taking care of that!