Today at 19:25 CET I announced the availability of the first official Beta release of MySQL Workbench.I wrote that this marks a milestone for my team and this is absolutely true. We have very high ambitions with this project for the years to come and getting the core of the implementation done right is crucial for any success. Sure there are still bugs, sure we still have to remove some rough edges but the core is there. And after 20 years coding since I wrote my first lines in Basic when I was 12, let me tell you – this core is right. And now we can stabilize and improve upon it.The last months have been quite a challenge for my team and myself. Working 50-80h weeks do mean serious compromises on your personal life but if you believe in something you are ready to walk the extra miles to get it done right.So at this point I would like to thank every member of the team (and the girlfriends who have been extra-forgiving) and all the people inside of MySQL who made this possible – you rock!We will continue to keep working hard for the next months to fix all bugs that our community and our SE Beta testers will report to get the tool stable and into RC and GA as soon as possible.MikeZp.s.: I’m sorry if this posting may sound a bit greasy but this was an emotional moment 🙂
If you are on Linux or OS X you might ask why we have decided to first release on the Windows platform. And why the releases for Linux and OS X will happen a few months later. Here is why.
We believe we can deliver better quality if we focus on one platform first. By having the whole team focusing on one platform we can get a release out sooner than it would be possible by supporting all three platforms from the beginning.
And the sooner we release, the earlier we get bug reports. And this benefits the quality. When we are going to release on the other platforms the back-end code will already be well community-tested. And even the first releases on Linux and OS X will have a decent quality.
But why did we choose Windows as the first platform? Actually, it was not us – it was you, our users. Looking at the bug reports we got for the old GUI tools it is clear that 90% of the reports are for Windows. And that made the choice easy.
The question remains why we do not use Java or a cross platform GUI toolkit. The answer for that is that a lot of developers do not want Java to be installed on their development machine. I personally love Java as a language but I can see their point, so that was not an option. For the cross platform GUI toolkits – we have tried a number of them. But non of them really delivered what we needed.
So I hope our fellow Linux and OS X users (I’m on OS X now as well) will understand our motivation behind this decision and will be even more happy when they are going to try Workbench on their platform and find it working very well.
The new MySQL Workbench version 6.2 has its usual share of new features but also brings some big improvements that will be very welcome even to long time users that only need the bread and butter basic functionality. Here’s the list:
Spatial Data Viewer
MySQL 5.7 will include much awaited GIS support for InnoDB tables. To make it easier to quickly visualize spatial/geometry data in geographic context, Workbench 6.2 includes a viewer for resultsets containing that type of data. The viewer will render data from each row as a separate clickable element. When clicked, you can view the rest of the data from that row in the textbox. If you have multiple queries with geometry data, you can overlay them in the same map.
Geometry Data Viewer
Both the Field and Form Editors were updated to support the GEOMETRY datatype. You can view geometry data like polygons from a single row as an image or as text, in any of the common WKT, GeoJSON, GML or KML formats.
MS Access Migration
MS Access support was added to the Migration Wizard in MySQL Workbench 6.2, joining MS SQL Server, Sybase ASE, Sybase SQL Anywhere, PostgreSQL, SQLite and “Generic ODBC” as migration sources. You can read more about it in How-To: Guide to Database Migration from MS Access using MySQL Workbench.
Metadata Lock Browser
MySQL uses metadata locking to manage access to objects (tables, triggers, and so forth). Sometimes that can be puzzling, as your query may block waiting on an object being manipulated by another connection from maybe another user. The Client Connections list was updated to take advantage of the metadata lock information provided in the performance_schema starting in MySQL 5.7.3, to show information about what locks a connection is waiting for and what it holds.
Updated Client Connection Browser
Speaking of the Client Connection browser, a neat feature added in MySQL 5.6 is the connection attribute dictionary, which includes handy things like the name of the clients that are connected (as long as the client supports it). You can access that by clicking the Show Details button in the Client Connection screen.
Improved Visual Explain
In MySQL 5.7, the Optimizer Team has been doing great work in refactoring as well as innovation with the new Cost Model. The improved Visual Explain enables the DBA to now get deeper insights into Optimizer decision making, for improved performance tuning of queries. The UI was also improved to allow easier navigation in large query plans.
Streamlined Query Results Panel
The query results panel was updated to centralize the many features related to result sets into a single location. Result Grid, Form Editor, Field Types, Query Stats, Execution Plan (including the traditional and Visual Explain) and the new Spatial Viewer are all easily accessible from a single interface.
SQL Snippets are useful to store queries and commands that are used often, but until now they could only be stored locally. In 6.2, you can now store snippets in the MySQL server you’re connected to and anyone anywhere who can access the .mysqlworkbench schema can also use these snippets.
MySQL Fabric Support
MySQL Fabric servers can now be added to the Workbench home screen. When clicked, these connections will dynamically query the Fabric server and individual connections for all the managed MySQL servers will be created. You can then connect to each instance as usual.
Run SQL Script
It often happens that people try to load gigantic SQL script files into the Workbench SQL editor just to execute them. That will rarely work, as loading files for editing uses a lot of memory and Workbench does a lot of processing in the editor (syntax highlighting, syntax checking, code folding etc). To execute arbitrarily large scripts easily, you can now use the dialog at File -> Run SQL Script: The dialog lets you preview a part of the script, specify a default schema (in case it’s not already defined) and a default character set to use when importing it. The output window shows warnings, messages and a nice progress bar.
Include Model Scripts in Forward Engineering and Synchronization
Workbench modeling has always supported attaching SQL script files to the model, usually for documentation/organization purposes. You can now include these attachments to the output script when performing forward engineering or synchronization.
Direct Schema Tree Action Buttons
- Table or Schema Inspector
- Object structure editor
- Table data browser/editor
- Call Stored Procedure or Function
Format Note Objects in Diagrams
Other improvements and bug fixes that make a difference
Resultset grid columns are now automatically resized to fit – and if you manually resize a column, the customized size is remembered, so next time you run that query again, the columns will be back to the size you left them.
Customize font for resultset grid – some people want to cram more text in the resultset grid, some people prefer bigger, easier to read text. Now you can pick what you like in Preferences.
Improved state saving for the SQL Editor – Opened, closed and reordered tabs are now properly saved and restored. The scroll position and cursor location is also remembered.
MySQL password is remembered for the session, even if not stored in the keychain, so you don’t need to re-enter it when a new connection is needed.
Keyboard shortcuts now work in the Scripting Shell.
Resume data copy in Migration Wizard. If a data copy fails during database migration (because of a timeout or network failure, for example), you can now click Resume to retry the data copy. Workbench will find the last row that was copied successfully and try to restart the copy from that row.
MySQL Workbench 6.2 also finally adds native 64bit support for Windows. This should allow working with larger data sets and script files. Oracle Linux/RHEL 7 support was added. To improve quality and user experience, we will be providing 64-bit binaries for Linux. Linux users who want 32-bit binaries, can compile from source.