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:
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

[3 Sep 2010 16:35] Karsten Wutzke
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).
[14 Sep 2010 22:32] Sveta Smirnova
Thank you for the report.

Please specify what you exactly do. Which plugin do you use.
[14 Sep 2010 22:53] Karsten Wutzke
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.
[16 Sep 2010 13:33] Alfredo Kojima
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("")?
[16 Sep 2010 13:40] Alfredo Kojima
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?
[16 Sep 2010 14:13] Karsten Wutzke
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.
[16 Sep 2010 14:23] Karsten Wutzke
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
        # 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).
[12 Nov 2010 22:46] Alfredo Kojima
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)
[26 Jan 2011 20:09] Karsten Wutzke
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.
[1 Feb 2018 10:48] Mike Lischke
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.