dbcli / mycli

A Terminal Client for MySQL with AutoCompletion and Syntax Highlighting.

Home Page:http://mycli.net

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

multiple connection / connection_ids in one mycli session

bddicken opened this issue · comments

In the default mysql command line connection interface, I can do something like this:

mysql> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
|              41 |
+-----------------+
1 row in set (0.00 sec)

mysql> select * from message order by alias desc limit 10;
^C^C -- query aborted
ERROR 1317 (70100): Query execution was interrupted
mysql> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
|              41 |
+-----------------+
1 row in set (0.00 sec)

In other words, show the connection ID, start executing a query, cancel it with control-C, and then afterwards it is still on the same connection / connID. However, in mycli:

MySQL root@(none):chat> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 44              |
+-----------------+

1 row in set
Time: 0.004s
MySQL root@(none):chat> select * from message order by alias limit 10;
q
^Ccancelled query
MySQL root@(none):chat> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 45              |
+-----------------+

It seems like control-C-ing a query causes the underlying CLI to establish a new connection. Is this expected behavior? If this is the desired end goal it ok, but it does make it a little bit annoying if I want to do some monitoring of a particular connection by connection ID. In this case, canceling a long-running query (and perhaps other events too) causes the underlying connection to change. When running a query to completion, it does not seem to do this.

MySQL root@(none):chat> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 48              |
+-----------------+

1 row in set
Time: 0.003s
MySQL root@(none):chat> select * from message limit 0;
+----+-------+------+------+------------+
| id | alias | room | text | created_at |
+----+-------+------+------+------------+
+----+-------+------+------+------------+

0 rows in set
Time: 0.003s
MySQL root@(none):chat> select CONNECTION_ID();
+-----------------+
| CONNECTION_ID() |
+-----------------+
| 48              |
+-----------------+

Not sure if this should be categorized as a bug or as a feature request :)

@bddicken Unfortunately, it is intended behavior. We establish a new connection when a long running query is interrupted with a Ctrl-C to regain the prompt.

Thanks for the fast reply!

Is there a particular reason for making a new connection in this circumstance? It is just easier to implement that way, or are there some other functionality goals for which this is required? To me (a newcomer to mycli) it does seem odd that the functionality would diverge from the built-in mysql in this way.

When mycli started it was built with an explicit goal of being user friendly and the compatibility with mysql client was an afterthought. We wanted to make it easy for someone to switch from mysql to mycli so we tried to keep the cli flags same and tried to match some of the CLI behaviors.

At that time if you hit Ctrl-C in mysql it didn't cancel the query, I wanted to fix that and I couldn't figure out a way to do it and still reuse the existing connection. So I found the next best thing, to drop the existing connection and establish a new one so the end user is unblocked to proceed with their next query.

Thanks for the background, and thank you for such a great tool! I'll close this issue out.