thank you for your constructive feedback. Some of it is already known and we are discussing changes, others is by design and requires more input from various sources on how to do it the right way. You know, people have a very diverse feeling about what is comfortable for them. Let me give you a few comments below:
> The Overview, Output, and Snippets tabs are
> confusing. The UI layout suggests the lower tab
> set is part of the SQL Query tab above it, but
> they are independent. However, querying using the
> query tabs above opens results in a tab
> immediately below, suggesting that they are
> interlinked. It also flickers to the 'Output' tab
> quickly before actually showing result sets - this
> is most annoying.
Well, this behavior is a trade off between functionality and available space. The tabs below consist of two different types:
- The general output, snippets and overview panes.
- The individual result set panes.
Still, there is room for improvement, even though other users might complain later when we rearrange this.
> One thought could be that the Overview, Output,
> and Snippets tabs are moved to the top row (at the
> same level as SQL Query tabs), and take over the
> entire double panel instead of being in just the
> lower area.
Then you can never see your query and potential error messages at the same time, making it much harder to find a syntax error etc.
> While I too wonder why on earth EDIT was
> introduced in the first place (certainly doesn't
> *help* usability...), I do have a few constructive
> pieces of feedback for the interface:
The EDIT keyword is a temporary construct to help determining which query actually returns an editable result set (as you know there are many restrictions that limit which result set is editable). With an improved parser we will later be able to find this automatically. This is an already planned change.
> 1. Double clicking table names in the left hand
> panel should do the exact same thing as double
> clicking them in the Overview - that is, open the
> table into a resultset. Preferably into the
> EDITable resultset. They even use the same icon!
The intention is that you can use the object tree to construct a complexer query (as it only inserts the text of the node you double clicked (also for individual columns, instead entire tables) while the double click on a table on the overview pane is meant to quickly open it for editing. Convenience.
> 2. It should also take a queue from Query Browser
> and NOT ACTUALLY EXECUTE the query immediately,
> but instead populate the query editor and allow me
> to execute it or modify it on my own - what if my
> database has millions of rows or is very slow!?
First, you still can do that by constructing your query using the object tree instead the overview (however I admit, the double listing of objects is something which can be improved as well). Second, WB limits result sets to 1000 rows by default. So large tables are not a problem (you can change the row limit in the application settings btw.). And double clicking a table on the overview pane executes a simple select * query there won't be any problems caused by complexer ones.
> 3. The edit interface is more confusing than the
> old Query Browser. It's confusing in that it seems
> like it's applying the actions immediately to the
> database (BAD - almost had a heart attack when I
> read 'Fetched 7 records, deleted 1' for the first
How did that happen? The WB resultset editor behaves much like the one in QB (except the color coding is not yet implemented). There is no immediate application of changed entries. You still have to click Apply to make them permanent.
> I also recommend moving the 'apply' and 'discard'
> buttons to another location, separated from the
> rest of the toolbar - perhaps on the far right,
Yes, they need to move.
> I realise that what I'm saying is basically: use
> the Query Browser editor, but the UI in the QB
> editor was much, much clearer and gave me a lot
> more confidence in what I'm actually going to be
> doing to my database at any given time! The UI in
> this feels more like Microsoft's SQL Management
> Studio, which has some good points, but suffers
> from the same problems with unclear actions.
Noted. Though, don't forget, getting used to a new tool sometimes means to change habits, which is almost always more or less annoying.
Mike Lischke, MySQL Developer Tools
Report bugs to http://bugs.mysql.com
MySQL documentation can be found here: http://dev.mysql.com/doc/refman/5.6/en/index.html