MYSQL Workbench 5.2.17 Beta

This release of Workbench has shown some major improvements. Especially in looks and feel, so I want to thank the team for those improvements at this time. I would like to take the opportunity though to point out some short commings or inconsistencies – at least in my oppinion. These are not bugs per say – for those see the bug reporting system – but just things that make using WB not as much pleasure as it could be.

1.) Triggers: Why can’t the handling of triggers be consistent with the way MYSQL stores/handles triggers. Namely each trigger as its own entity. Currently triggers just roll together in the sample as shown below in an example that does nothing but is just used to describe the problem

– Trigger DDL Statements
DELIMITER $$

USE `test`$$CREATE DEFINER=`admin`@`%` TRIGGER `beforeinsert`
BEFORE INSERT On table1
FOR EACH ROW
BEGIN
    SET new.field1= new.idtable1;
END$$CREATE DEFINER=`admin`@`%` TRIGGER `beforeunsert`
BEFORE UPDATE On table1
FOR EACH ROW
BEGIN
    SET new.field1= new.idtable1;
END$$

As you can see the triggers just run into each other. At least the coloring helps a bit but it is still difficult to find/handle/change something.

If you execute a SHOW trigger command you get the triggers data  neatly seperated in columns like

TRIGGER EVENT STATEMENT ,,,,, etc

Why not make a seperate tab for each trigger (as it is a row in a table) and then display each field for some data. This should greatly improve the handling of triggers in the system. If also should make the synchronizing easier as each field already has its own value. That way lots of unnecessaty updates could be eliminated.

2.) User defined Data Types: MYSQL currently does not suppor them. It would be nice to have. But currently this feature is unreliable and can be dangerous. It should only be included in the system if it can be implemented in a rock solid way. It would be nice to have User Defined Data Types to help with consistency through the system and allow systemwide changes when for example it is found that a field size – like for example a customer # or part # fieldd – must change. Mosty for key/index fields used to help keep up the relations between tables. If a single update from the schema to the model can wipe out the Custom Data Type and replace it with a VARCHAR(whatever) or something like that then the whole concept of having the User Defined Data Types in the model is defeated. Some way to store it at the server side would have to be found – either as part of the comment for that particular field – or waiting until MYSQL actually supports user defined Data Types.

3,) Schema Privileges: WB has a whole section devoted to that. One that currently does absolutely nothing of use in my oppinion. Maybe that is why I could not find a help entry in the help system on it. True it lets you create users and define roles. Roles fall in the same category as User Defined Data Types as MYSQL currently does not support User Defined Roles. Currently in WB you can define a role and give that role certain privileges like (INSERT, SELECT…..) on particular tables and then you cann assign those roles to Users that you create. All very nice and reminiscent to featurs available in other SQL systems – but currently nothing more thant a notepad as it does not update the server.

Any user created in the model will not create a user on the Server side and any privilege granted to the User will not propagate to the server. In my opinion it is currently at best a notepad on what rights one might want to set up manually at the server ….

Again I would like to either – preferably – have this feature turned into a reliable solid tool – or removed as it does not do anything really useful at this time and could cause confusion and anger in the user. After all I might have spent hours setting up a Roles/User System in WB and now I got nothing at the server side and got to do it manually there…..

Lastly it would be nice if they could include a debugger into that system that allows you to debug your Stored Procedures/functions/triggers and step through them – but I guess I can keep hopeing.

Overall I would like to say that the project is moving in the right direction and I am using WB currently to develop my current project. So keep up the good work

2 Responses to “MYSQL Workbench 5.2.17 Beta”

  1. [...] MYSQL Workbench 5.2.17 Beta « Martin's MYSQL Blog [...]

  2. [...] original here: MYSQL Workbench 5.2.17 Beta « Martin's MYSQL Blog If you enjoyed this article please consider sharing [...]

Leave a Reply