| Bug #69531 | ASCII columns register as changed every time | ||
|---|---|---|---|
| Submitted: | 20 Jun 2013 20:07 | Modified: | 22 Aug 2013 14:45 |
| Reporter: | Rasmus Schultz | Email Updates: | |
| Status: | Verified | Impact on me: | |
| Category: | MySQL Workbench: Modeling | Severity: | S3 (Non-critical) |
| Version: | 6.0.6 GA | OS: | Any |
| Assigned to: | CPU Architecture: | Any | |
[20 Jun 2013 20:07]
Rasmus Schultz
[21 Jun 2013 4:49]
Alfredo Kojima
I could repeat this as described, thank you for the bug report.
[21 Jun 2013 14:15]
Alfredo Kojima
Posted by developer: Fixed in repository.
[27 Jun 2013 13:17]
Rasmus Schultz
Thank you so much for all your hard work, guys - very happy to see the MySQL Workbench project moving along again. Can't wait for the next release! :-)
[10 Jul 2013 15:35]
Rasmus Schultz
It appears this still does not work in the 6.0.3 beta. Columns with the ASCII attribute no longer register as changed, but now they don't register as changed, ever - regardless of whether you're changing a column to or from ASCII, the change isn't detected during "Synchronize Model" at all. Note that I'm using User Types in my project - so I'm not changing any of the columns *directly*, but rather changing a User Type to/from ASCII. It's also worth noting that there is currently no way to specify the ASCII or UNICODE attributes on a column directly, and I wonder if I should open a separate issue for this? (the BINARY attribute can be applied directly.) In other words, because I want to use ASCII, I have no other choice than to create a User Type, and unfortunately that still doesn't seem to work.
[11 Jul 2013 0:11]
Alfredo Kojima
Can you provide a test model and a schema dump of what you're testing where a diff should be detected but it isnt?
[11 Jul 2013 1:45]
Rasmus Schultz
Use the project I provided previously - apply the ASCII attribute to the "TYPENAME" User Type, for example.
[16 Jul 2013 22:03]
Alfredo Kojima
I can't repeat this. I created a model with an ASCII varchar(32) UDT column and then: 1 - forward engineered it, which created a utf8 table with a varchar(32) column with latin1 charset 2- synchronized, which resulted in no diffs 3- changed the UDT to remove the ASCII flag 4- synchronized, which resulted in an alter script without the ASCII flag, which once executed removed the latin1 charset from the column and left it in the default charset Can you provide the exact case you're talking about?
[16 Jul 2013 22:13]
Rasmus Schultz
Alfredo, I'm using CHAR not VARCHAR, I wonder if that makes a difference?
[17 Jul 2013 14:01]
Alfredo Kojima
CHAR vs VARCHAR shouldn't matter, there's no distinction made for both for this part. Can you paste the fwd engineer script and the SHOW CREATE script of the the table that you try to sync and gives no results? The ASCII flag is not stored by the server, instead it's interpreted as an alias to CHARACTER SET latin1, so it could be that both source and target are latin1 in your case, which would mean that toggling the ASCII flag is a no-op.
[19 Jul 2013 2:32]
Rasmus Schultz
Project was attached here previously: http://bugs.mysql.com/bug.php?id=68369#f20208 Apply the ASCII attribute to the "TYPENAME" User Type, as explained above.
[23 Jul 2013 12:43]
Alfredo Kojima
OK, now I get what you mean. The problem is that unsetting the ASCII flag will keep reporting differences in future syncs, even if the generated script is correctly missing the ASCII flag. That is because to undo the effect of creating a column with the ASCII flag, one would have to change the charset from latin1 to match table default. That'll be a little bit trickier but is uncommon, so we'll lower priority and come back to it later.
[23 Jul 2013 12:53]
Rasmus Schultz
I prefer CHAR ASCII when I need to use string-based primary keys, because those same strings are used literally in the software that persists to those tables. It's not tremendously important - I can just switch to regular CHAR instead of CHAR ASCII for this project.
[31 Jul 2013 17:07]
Philip Olson
Fixed as of MySQL Workbench 6.0.3, and here's the changelog entry: During synchronization, "CHAR(*) ASCII" columns would always be registered as changed. Thank you for the bug report.
[31 Jul 2013 17:12]
Philip Olson
Actually, this bug is still open.
[22 Aug 2013 14:45]
Rasmus Schultz
To be clear, this issue was not "fixed", the behavior was merely changed so that the ASCII modifier is ignored completely. So this issue still affects 6.0.6 GA, but no longer leads to redundant migrations - instead, changes to the ASCII modifier are simply ignored.
