MySQL Bugs: #71196: Mysql Workbench "History Output" fails to handle change of date

Bug #71196	Mysql Workbench "History Output" fails to handle change of date
Submitted:	20 Dec 2013 22:57	Modified:	25 May 2018 10:26
Reporter:	Dan Hi	Email Updates:
Status:	Verified	Impact on me:	None
Category:	MySQL Workbench	Severity:	S1 (Critical)
Version:	6.3.10	OS:	Windows (All)
Assigned to:	Miguel Tadeu Mota	CPU Architecture:	Any

Description:
This "History Output" window is keyed by the current date, for example "2013-12-20". You can select different dates by clicking on them in the "Date" window to the left of the "History Output." The contents of the "Output" window are stored in a file in:

"%appdata%\MySQL\Workbench\sql_history"

named by date: "2013-12-20"

When the date changes, and a new sql command is run, a new entry is created in the "Date" window, but the underlying file is not created. Instead, workbench continues writing to the history file that was created when Workbench was opened, say 2013-12-16.

When you click on "2013-12-20," it refreshes the output window, or appears to, but instead of loading the contents of the (nonexistent) file, it shows the contents of whatever was the last date successfully opened.

You can have multiple rogue entries if you leave workbench open all week. Once you restart workbench, the rogue entries go away, but all of your history is stored in the original date of opening. So, you might have all your history in a single file, named "2013-12-16", but which contains history for the entire week of 12-16 through 12-20.

How to repeat:
Open workbench at 11:58pm.
Run a query, and watch it appear in the History output under today's date.
Click on an older date.
Wait until 12:00am.
Run a query.
Click on today's date, but nothing loads--instead it shows the data from the older date.
Click on yesterday's date, and observe the item is there, instead.
Restart workbench.
Observe that the new entry for today's date is gone, and only the date for yesterday shows up.

Suggested fix:
Have workbench close the old file and open a new one, if it observes that the date has changed.

The default behavior of the window is also poor, which makes this worse. When you open the "Date," it defaults to scrolling to the end, which is the oldest date. You have to scroll to the top, and choose today, just to see the most recent history.

Then, the history window has the same issue. It scrolls to the end, which is the oldest items for today (or this week, because of the bug).

Thanks to this scrolling issue, by the time you want to look at history output, it currently has selected the oldest possible date. Then you click on today, but it doesn't load, and you are extremely confused by what you see ("when did I do THAT query?"). What you see is the queries done the first day you installed workbench...

I originally reported this for 6.0.8.11354 build 833.  Disappointingly, there has been no progress nor any comments on the bug.  Updating the form to the current version as the bug still persists.

Still not working.

I can explain more:

The date is the date of the tab.
If I was opened a tab on 2014-04-08, and opened an other tab in 2014-04-23, the first tab history will be logged in  2014-04-08  file until Workbench crash or tab closed, and the second tab on  2014-04-23.

If it's intentional that the date / file selector is stuck on the day it is opened then it should not create new date/file options that do not exist.  E.g., I opened it yesterday and I have an option to select 2014-04-24 even though there is no file for today.

It is more intuitive for the date/file to represent the actual date of the operations.  E.g. if I recall doing something on Tuesday, why should I have to also remember that the operations are not stored in the Tuesday option but that I had opened workbench last week and I must choose the correct date of opening and not any of the false non-existent date file options.

Moshe,

Your comment does not appear to be accurate.  I just opened a tab, executed a query, and it showed up under 2014-04-24.  I then changed the date to 2014-04-25.  I then created a new tab, and executed a new query.  The date 2014-04-25 did show up in the history, but no file was created, and no query was listed.  Instead the query was still listed under 2014-04-24.

In summary:

1. The create time of the tab is irrelevant, and the date that is used to store the query is the date of workbench opening.
2. By changing the date, your query will cause a dummy history group for that date to be created, but your query will not be stored in that date, but rather the date of workbench opening.
3. It is not necessary to create a new tab to get workbench to generate a dummy history group for a new date.

This test just confirms the originally reported bug. Even if what you said was true, however, it would not be proper behavior.  The history items should fall under the date that the query was executed, not the arbitrary date of whenever a tab (or workbench) was opened.  By storing in this way, you lose information of what date a query was actually executed on, and gain useless information about the last time workbench was started before executing a query.  The dummy date groups just make it more confusing as they can be clicked on but don't work.

I can repeat by executing a query after changing the system date

Posted by developer:
 
Fixed. Needed to update the timestamp on the history backend.

Fixed as of an upcoming MySQL Workbench 6.2.x  release, and here's the changelog entry:

The "History Output" window failed to handle a change to the system's
date.

Thank you for the bug report.

I just tested this again with 6.2.3.12312 build 2280.  The exact same behavior persists.

Which upcoming 6.2.x release was meant to have the fix?

Please try version 6.3.5. Thanks.

It doesn't quite work in 6.3.5.

After starting 6.3.5 fresh, I performed a query.  The query created a History entry for 2015-11-05.  I changed the date to 11-6, and did another query.  The Date widget scrolled to the bottom and selected the first query in the list (2011-01-20).  I scrolled back up, and clicked on the new entry called 2015-11-06.  It showed me the first line from the entry 2011-01-20.

I looked at the file for 2011-11-06, and saw that it contained:

<?xml version="1.0" encoding="UTF-8" ?>
<ENTRY timestamp='16:12:53'>~</ENTRY>

The ~ appears to indicate that the same query was repeated.  This causes a different bug, in that whatever history file you had clicked on last is used to fill in the ~.

I tried it with different queries across the date range and that appears to work correctly.  However, it doesn't select the new date (instead selecting the very bottom item, which is the first day you used workbench) when a new date file is created, which seems like a usability flaw, if not a bug.

Plese try version 6.3.7. Thanks.

No feedback was provided for this bug for over a month, so it is
being suspended automatically. If you are able to provide the
information that was originally requested, please do so and change
the status of the bug back to "Open".

Using 6.3.9 this bug still exists.

Has anyone actually tried to fix this bug?  Or do you just keep posting "try the latest version" hoping someone else fixed it?

Thank you for the bug report.

The same behavior I noted in my previous post still exists.  The history files are now created correctly across date ranges, but the "~" entry is still broken as it repeats the entry from the last history date clicked on.  Combined with the fact that a new "day" will cause it to scroll to the last date in the list, the "~" entry is very likely to show the wrong data.

If you wish, I can submit a new bug, since you seem to be ignoring the issues I've detailed in this one, and have now closed this bug.