MySQL Bugs: #50110: Workbench not proper parse the decimal data type with reverse engineer function

Bug #50110	Workbench not proper parse the decimal data type with reverse engineer function
Submitted:	6 Jan 2010 18:36	Modified:	9 Feb 2010 14:06
Reporter:	Wagner Pinheiro	Email Updates:
Status:	Closed	Impact on me:	None
Category:	MySQL Workbench: Modeling	Severity:	S2 (Serious)
Version:	5.2.11-beta	OS:	Linux (Ubuntu Karmic Koala 9.10)
Assigned to:	Alexander Musienko	CPU Architecture:	Any
Tags:	decimal, reverse, synchronize, workbench

Description:
The Workbench not proper parse the decimal data type when using the "reverse engineer" and the "synchronize model" functions. The scale (number of digits to the right of the decimal point) of decimal type is defined with "0".

Details from the server:
Ubuntu Karmic
Linux 2.6.31-16-generic x86_64 GNU/Linux
MySQL 5.1.37-1ubuntu5-log

How to repeat:
1)create a table in database with decimal data type like:
CREATE  TABLE IF NOT EXISTS `test`.`cad_prod_det_icms` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `predbc` DECIMAL(17,5) NULL DEFAULT NULL ,
  `picms` DECIMAL(5,2) NULL DEFAULT NULL ,
  PRIMARY KEY (`id`) ,
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_general_ci;
2)use the workbench to reverse the table, in that case the field 'predbc' became with data type 'decimal(17,0)' and the field 'picms' with data type 'decimal(5,0)'
3)if you change the model and fix the data type to match with the original table and use the function "synchronize model", the table in database is set with the wrong data type with scale '0'

correction: the error only occurs with the function 'synchronize model'

rev-engineering that example table from database worked fine (shows correct decimal settings for the two columns), but changing the val. to i.e. DECIMAL(17,2) and trying to sync didnt pickup the difference for me (tried on 5.2.11 macos connected to 5.1.37 server on ubuntu)

Hi,

  Let's try again. The problem occurs when the default value of column is set in the table definition and this only occurs with the 64bits version of the Mydqld. I tried  with the Xampp in a windows 32bits and the bug not appears.
  How to reproduce:
  1) in a 64bits version of mysqld server, create a table:

drop table if exists `test`.`cad_prod_det_icms`;

CREATE  TABLE IF NOT EXISTS `test`.`cad_prod_det_icms` (
  `id` INT(11) NOT NULL AUTO_INCREMENT ,
  `predbc` DECIMAL(17,5) NULL DEFAULT 10.12345 ,
  `picms` DECIMAL(5,2) NULL DEFAULT 1.23 ,
  PRIMARY KEY (`id`)
)
ENGINE = InnoDB
DEFAULT CHARACTER SET = latin1
COLLATE = latin1_general_ci;

    2) run the Workbench and do a 'reverse enginneer' (I tried with the 64bits version of Workbench in Ubuntu and the 32 bits in windows)
    3) Use the 'synchronize model' function. The alter sql result is like:

ALTER TABLE `test`.`cad_prod_det_icms` CHANGE COLUMN `predbc` `predbc` DECIMAL(17,0) NULL DEFAULT NULL  , CHANGE COLUMN `picms` `picms` DECIMAL(5,0) NULL DEFAULT NULL  ;

Thank you for your bug report. This issue has been committed to our source repository of that product.

An entry has been added to the 5.2.16 changelog:

When synchronizing a schema with a live server, the scale of columns with type DECIMAL was erroneously set to zero. For example, a DECIMAL(17,5) was found to be set to DECIMAL (17,0) in the generated script.