MySQL Bugs: #56544: Workbench silently saves to customData

Bug #56544	Workbench silently saves to customData
Submitted:	3 Sep 2010 16:35	Modified:	1 Feb 2018 10:48
Reporter:	Karsten Wutzke	Email Updates:
Status:	Won't fix	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S3 (Non-critical)
Version:	5.2.26, 5.2.27	OS:	Any
Assigned to:		CPU Architecture:	Any
Tags:	custom data, save

Description:
When operating certain plugins that store data (options, etc.) in the customData dict, exiting the model after having changed one or more of its items, Workbench used to indicate this via the * symbol and would display a dialog box upon exit.

While at first it might seem wrong to display the dialog because the model itself hasn't changed, this is the only way to detect that a plugin has changed its custom data.

Now when changing customData, the user would not be notified of changes, nor will a star * symbol indicate that anything has changed in the model. Performing a manual Ctrl-S / save via menu will actually update the new customData, but only then. This behavior seems to have changed with version 5.2.26.

How to repeat:
see desc

Suggested fix:
My suggestion would be to indicate changes to customData via the star symbol (*), but the dialog displayed should clearly indicate that not the model itself but customData had changed.

If this is too complicated, as both the model and customData might change at the the same time, I'd be happy if the previous policy would be restored (display that the model has changed).

Thank you for the report.

Please specify what you exactly do. Which plugin do you use.

I use my own, unpublished plugin. I save plugin options to customData which used to cause a star * when the options were changed. This has been changed either with version 5.2.26 or 5.2.27.

Please contact the developers who dealt with bug http://bugs.mysql.com/bug.php?id=56009. They should know whether they changed this.

What "type" of plugin is it? Do you have your own UI and perform these changes interactively?
If so, are you using Workbench.startTrackingUndo() and finishTrackingUndo("")?

FYI nothing has been changed in regard to this behaviour. In what previous version did things behave as you describe? Was it the same plugin?

I didn't realize when I reported this that WB doesn't save silently. However, before that fix I believe WB recognized a change in the customData (plugin options) and marked the file as changed (star symbol * in the window title). I realized later that WB will not display a dialog anymore when customData was touched.

It was the very same plugin and it doesn't use any of the undo methods. Here's the code I use:

    # empty options dict
    options = {}

    # if custom plugin options dict exists, use it
    if not catalog.customData.has_key('hibernateExportPluginOptions'):
        # print "NEW OPTIONS!!"
        # store empty dict in model
        catalog.customData['hibernateExportPluginOptions'] = options
    else:
        # print "HAS OPTIONS!!"
        options = catalog.customData['hibernateExportPluginOptions']

    didAccept = Gui.askForOptions(options)

The askForOptions method will save new values to that dictionary. In previous versions, the changes there were recognized by WB, now this is no longer the case.

It appeared as a silent save, but it saves nothing at at all. Now when I forget to manually save the model after changing the plugin options, they're gone. Previously, WB owuld at least notify the user of changes in the model (options dict saved in customData).

Hi Karsten,,

Does that code work at all, even if you save the model explicitly regardless of it displaying a change indicator? I'm not sure, but at least for the case that there's not yet a hibernateExportPluginOptions dict already stored, it will not work, because didAccept = Gui.askForOptions(options) will be writing to the Python dictionary, not the one stored by Workbench. If you want that to work, you need to change the code to:

    options = {}

    # if custom plugin options dict exists, use it
    if not catalog.customData.has_key('hibernateExportPluginOptions'):
        # print "NEW OPTIONS!!"
        # store empty dict in model
        catalog.customData['hibernateExportPluginOptions'] = options

    options = catalog.customData['hibernateExportPluginOptions']

    didAccept = Gui.askForOptions(options)

Hmm I have changed the code meanwhile, but that isn't the point here anyway. The behavior that changed is that when you used to store something in customData, WB would indicate that via a star symbol in the window title, which is no longer the case.

This means any plugins saving to customData will not inform the user that something has changed and possibly changed options aren't saved when cloding WB then.

Posted by developer:
 
The behavior is as designed and even though it could be improved we have no plans to fix/enhance plugin support in Workbench in the foreseeable future.