REGRESSION: datetime fields lose microsecond precision

[GoogleCodeExporter]

What steps will reproduce the problem?

1. Install tungsten replicator 3.0.1-30 using MySQL 5.6+
2. use row binlog-format
3. create a table with a datetime field, using any microsecond precision, and 
insert a value

set global binlog_format=row;
create table t1 (id int not null primary key, dt datetime(4));
insert into t1 values (1, '2014-12-07 11:09:09.1234');
select * from t1;
+----+--------------------------+
| id | dt                       |
+----+--------------------------+
|  1 | 2014-12-07 11:09:09.1234 |
+----+--------------------------+

4. check the result in the slave

What is the expected output?

same as the master

What do you see instead?

The microseconds portion was lost.

 select * from t1;
+----+--------------------------+
| id | dt                       |
+----+--------------------------+
|  1 | 2014-12-07 11:09:09.0000 |
+----+--------------------------+

thl list -seqno 4
SEQ# = 4 / FRAG# = 0 (last frag)
- TIME = 2014-12-07 04:13:58.0
- EPOCH# = 0
- EVENTID = mysql-bin.000002:0000000000001139;-1
- SOURCEID = gmini
- METADATA = 
[mysql_server_id=101;tz_aware=true;dbms_type=mysql;service=tsandbox;shard=test]
- TYPE = com.continuent.tungsten.replicator.event.ReplDBMSEvent
- OPTIONS = [foreign_key_checks = 1, unique_checks = 1, time_zone = '+00:00']
- SQL(0) =
 - ACTION = INSERT
 - SCHEMA = test
 - TABLE = t1
 - ROW# = 0
  - COL(1: ) = 1
  - COL(2: ) = 2014-12-07 11:09:09.123400000

What is the possible cause?

N/A

What is the proposed solution?

N/A

Additional information

...

Use labels and text to provide additional information.

Original issue reported on code.google.com by g.maxia on 7 Dec 2014 at 4:24

[GoogleCodeExporter]

Note: the command for binlog format should run without "global".

This issue affects also installations using MariaDB 10.0.10+

Original comment by g.maxia on 7 Dec 2014 at 4:38

[GoogleCodeExporter]

Thanks, this does look like a regression. The root cause is an error the 
applier formatting for time-related datatypes, which needed to be replaced in 
order to ensure clean upgrade and avoid reverting fixes to Issue 1053.  

Original comment by berkeley...@gmail.com on 7 Dec 2014 at 5:07

[GoogleCodeExporter]

This issue was updated by revision r2697.

Corrected formatting of MySQL DATETIME in applier to apply nano-second 
precision correctly.  Also fixed along the way an bug in initializing SQL load 
scripts in SqlConnectionManager that popped up in time-related data testing.  
(Scripts were being ignored.)

Original comment by robert.h...@continuent.com on 9 Dec 2014 at 11:41

[GoogleCodeExporter]

This bug is fixed in the replicator trunk.  The problem was that in accounting 
for formatting of old logs  I took a shortcut that mistakenly removed the 
nanosecond time formatting.  To handle it correctly I added back another 
formatter specially for MySQL DATETIME values that remains on GMT even when 
processing old logs. 

Original comment by robert.h...@continuent.com on 9 Dec 2014 at 11:46

[GoogleCodeExporter]

Verified. 
There is already a thorough test in the regression suite (which caught this 
problem)

Original comment by g.maxia on 10 Dec 2014 at 3:20

• Changed state: Fixed

[GoogleCodeExporter]

This issue was updated by revision r2698.

Merged fix to correct formatting of MySQL DATETIME in applier to apply 
nano-second precision correctly. 

Original comment by robert.h...@continuent.com on 10 Dec 2014 at 5:42

[GoogleCodeExporter]

Fix is also merged to 2.2.1 branch.  We are all done on this one. :)

Original comment by robert.h...@continuent.com on 10 Dec 2014 at 5:43