Description:
When synchronising two models, Workbench suggest altering columns that are identical in both models.
Example:
The syncing two models (created from SSHed Debian Lenny + MySQL 5.0.51a vs. local Windows 7 + 5.1.53) gives:
"ALTER TABLE `ug`.`karma` CHANGE COLUMN `zz_timestamp` `zz_timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP ;"
even though the `karma` in both models is identical:
CREATE TABLE karma (
id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT,
poster_id INT(10) UNSIGNED NOT NULL,
voter_id INT(10) UNSIGNED NOT NULL,
post_id INT(10) UNSIGNED NOT NULL,
vote ENUM('up','down') NOT NULL,
zz_timestamp TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (id),
UNIQUE INDEX voter_id_post_id (voter_id, post_id),
INDEX `poster_id, voter_id, post_id` (poster_id, voter_id, post_id),
INDEX postId_vote (post_id, vote)
)
COLLATE='latin1_swedish_ci'
ENGINE=MyISAM;
How to repeat:
Happens every time with the setup described. Didn't try replicating on different instances, but this should never happen if both models are identical regardless of hardware/software setup.
Suggested fix:
The problem started to surface when we started using TIMESTAMP columns with DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP option. Since then, all columns with that option started producing unwanted (as described) behaviour when syncing models.
Description: When synchronising two models, Workbench suggest altering columns that are identical in both models. Example: The syncing two models (created from SSHed Debian Lenny + MySQL 5.0.51a vs. local Windows 7 + 5.1.53) gives: "ALTER TABLE `ug`.`karma` CHANGE COLUMN `zz_timestamp` `zz_timestamp` TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP ;" even though the `karma` in both models is identical: CREATE TABLE karma ( id INT(10) UNSIGNED NOT NULL AUTO_INCREMENT, poster_id INT(10) UNSIGNED NOT NULL, voter_id INT(10) UNSIGNED NOT NULL, post_id INT(10) UNSIGNED NOT NULL, vote ENUM('up','down') NOT NULL, zz_timestamp TIMESTAMP NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (id), UNIQUE INDEX voter_id_post_id (voter_id, post_id), INDEX `poster_id, voter_id, post_id` (poster_id, voter_id, post_id), INDEX postId_vote (post_id, vote) ) COLLATE='latin1_swedish_ci' ENGINE=MyISAM; How to repeat: Happens every time with the setup described. Didn't try replicating on different instances, but this should never happen if both models are identical regardless of hardware/software setup. Suggested fix: The problem started to surface when we started using TIMESTAMP columns with DEFAULT CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP option. Since then, all columns with that option started producing unwanted (as described) behaviour when syncing models.