Description:
The behavior of this bug seems to depend on whether a table was created with the layout tool or imported with Reverse Engineering.
While editing a table with the Table Editor, there are two different places to change the ZEROFILL and UNSIGNED flags ("FLAGS"): in the Columns tab pane or in the Advanced "Column Details" pane.
When editing a table created with the Table tool in the Layout
------------------------------------------------------------
Only the changes made in the "Advanced" area are kept.
Changes made in the "Advanced" area are actively reflected in the "Columns" tab.
Changes made in the "Columns" tab are NOT actively reflected in the "Advanced" area.
When editing a table created imported by Reverse Engineering
------------------------------------------------------------
No changes made to the FLAGS persist after closing and re-opening the Table Editor.
Changes made in the "Advanced" area are actively reflected in the "Columns" tab.
Changes made in the "Columns" tab cause the "Advanced" area flags to be cleared.
While there seems to be a workaround for tables created in Layout, it seems not possible to have UNSIGNED or ZEROFILLed columns on any tables Reverse Engineered.
How to repeat:
1) Create a table to import
CREATE TABLE `foo` (`bar` int(4) PRIMARY KEY);
2) Import the table by Reverse Engineering using default options.
3) In the Layout view, click the "pencil" of the table `foo`
4) Select `bar` in the "Columns" tab.
The FLAGS are clear in both the "Advanced" pane and the "Columns" tab.
6) adjust FLAGS in each area, note the behavior described above.
7) Close the Table Editor, use the Table Tool to create a new table in the Layout. "Pencil" this table to view the editor.
8) Note the different behavior as described above.
Suggested fix:
The desired behavior is to have the two FLAGS edit areas properly update each other, and for those changes to persist when the Editor is closed.
Of couse the great fear is in why the behavior is different for tables created by these two different avenues as this could be a clue to some other underlying problem.
Description: The behavior of this bug seems to depend on whether a table was created with the layout tool or imported with Reverse Engineering. While editing a table with the Table Editor, there are two different places to change the ZEROFILL and UNSIGNED flags ("FLAGS"): in the Columns tab pane or in the Advanced "Column Details" pane. When editing a table created with the Table tool in the Layout ------------------------------------------------------------ Only the changes made in the "Advanced" area are kept. Changes made in the "Advanced" area are actively reflected in the "Columns" tab. Changes made in the "Columns" tab are NOT actively reflected in the "Advanced" area. When editing a table created imported by Reverse Engineering ------------------------------------------------------------ No changes made to the FLAGS persist after closing and re-opening the Table Editor. Changes made in the "Advanced" area are actively reflected in the "Columns" tab. Changes made in the "Columns" tab cause the "Advanced" area flags to be cleared. While there seems to be a workaround for tables created in Layout, it seems not possible to have UNSIGNED or ZEROFILLed columns on any tables Reverse Engineered. How to repeat: 1) Create a table to import CREATE TABLE `foo` (`bar` int(4) PRIMARY KEY); 2) Import the table by Reverse Engineering using default options. 3) In the Layout view, click the "pencil" of the table `foo` 4) Select `bar` in the "Columns" tab. The FLAGS are clear in both the "Advanced" pane and the "Columns" tab. 6) adjust FLAGS in each area, note the behavior described above. 7) Close the Table Editor, use the Table Tool to create a new table in the Layout. "Pencil" this table to view the editor. 8) Note the different behavior as described above. Suggested fix: The desired behavior is to have the two FLAGS edit areas properly update each other, and for those changes to persist when the Editor is closed. Of couse the great fear is in why the behavior is different for tables created by these two different avenues as this could be a clue to some other underlying problem.