Feature Request: Don't Lock Interface During Query Execution

[DCrouse]

When executing a long-running query, I notice the interface doesn't allow the following:

– Editing the contents of the query tab

– Creating new query tabs

– Switching between query tabs within the current connection

– Switching between subtabs in the query window (i.e. Profiler, History)

Other tools I've used allow this (Toad for Oracle, for instance – if you enable threaded queries) and I've found it incredibly useful – being able to continue work on a statement while running a test, etc. Considering a purchase – this was one of my listed cons.

[nithin]

Hello,

Latest SQLyog (since version 8.5) we have implemented the Tabbed-interface for connections. So your request can be achieved by opening multiple connections to same server and is possible to switch to other connection-tab while other is executing a long-running query. Let me know your thoughts.

Regards

Nithin

[peterlaursen]

Clarification: the point is different query tabs *in the same connection window* use the same connection to MySQL.  Opening a new connection can be expensive and slow. But you have the option to have multiple connections open.

[DCrouse]

Correct – I did notice that movement between connections is still enabled and I think that's the right idea, but as a user I'd like to see this taken a step further:

Instead of the parent (connection) tabs representing a single connection, they could each represent a group of sessions using the same connection parameters, and each of the child (query) tabs would manage their own database session behind the scenes. The user fires off a long running query/procedure from Tab 1 and decides to peek at some dictionary tables/metadata/etc – by simply opening a new query tab (no need to go through Connection Mgr) and the application creates an independent session for any statement run from it. And the other note I added is that the user should still be able to modify the statement or add statements to Tab 1 during execution.

It may be a technicality, but it is very useful to be able to move around unhindered like this. The interface is very well organized as it is, and I think adding some more function to it would be great.

[peterlaursen]

“they could each represent a group of sessions using the same connection parameters, and each of the child (query) tabs would manage their own database session behind the scenes”.

Problems are:

1) the (global or per-user) max-connections settings on the server may not allow too many connections

2) In particular with SSH-tunnelling it will be costly and sometimes slow too (reverse DNS lookup is involved).

[DCrouse]

'peterlaursen' wrote on '17:

Problems are:

1) the (global or per-user) max-connections settings on the server may not allow too many connections

2) In particular with SSH-tunnelling it will be costly and sometimes slow too (reverse DNS lookup is involved).

There aren't really any added issues with this approach vs. requiring the user to go through the connection manager to open a new session (and displaying that session as a separate parent tab vs. a query tab under the parent.) Getting into implementation details here, but you could even have it “clean up” after itself – closing sessions after the statement is executed and opening them as needed. I don't think this is necessary though.

It's really just an improvement to the presentation of work spaces (in my opinion.)

[Author]

Posts