Bug #80255 treatment of current_timestamp() for timestamp datatypes
Submitted: 3 Feb 2016 17:52 Modified: 13 Feb 2018 6:41
Reporter: John Allan Email Updates:
Status: Duplicate Impact on me:
None 
Category:MySQL Workbench Severity:S3 (Non-critical)
Version:6.3.6 OS:Windows (7 professional)
Assigned to: CPU Architecture:Any

[3 Feb 2016 17:52] John Allan
Description:
If the default value of a timestamp datatype is CURRENT_TIMESTAMP() workbench provides incomplete information about tables in only some locations on the system. Specifically it doesn't present columns after the timestamp when you right click in schemas for alter table or reverse engineer a model. It also doesn't show indexes or foreign keys.

5.7 documentation indicates that CURRENT_TIMESTAMP() is treated the same as CURRENT_TIMESTAMP which is what the import displayed as the final definition.

Also of note is that this was identified after trying to upgrade from 6.2 to 6.3.6. A backup/export was done with the 6.2 version and after unsuccessfully upgrading I simple uninstalled and reinstalled the current version. 

How to repeat:
The 6.2 backup creates this column definition which was never reported as a problem - although I can see some deprecation issues with the documentation
  `UPDATE_TIME` timestamp(6) NOT NULL DEFAULT CURRENT_TIMESTAMP(6),
The import creates
   UPDATE_TIME timestamp with a default of CURRENT_TIMESTAMP()

Using workbench ALTER TABLE WON'T let you simply remove the (). However changing it to "CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP" overcomes the problem and all columns appear as well as indexes and FK's. Further changing it back to "CURRENT_TIMESTAMP" also works.

Suggested fix:
If () or (6) is no longer valid:
- show an error or warning somewhere in workbench
- fix during backups
- warn and fix during imports

Without any warnings and a visual definition on the alter table screen that is okay according to the documentation, tracking this was a little lucky.
[13 Feb 2018 6:42] MySQL Verification Team
Hello John Allan,

Thank you for the report.
This is most likely duplicate of Bug #88367, please see Bug #88367

Thanks,
Umesh