Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Not a Bug
-
10.0(EOL), 10.1(EOL), 10.2(EOL), 10.3(EOL)
-
None
Description
CONNECT engine truncates microseconds in TIMESTAMP/DATETIME values upon storing them:
MariaDB [test]> create table tc (t timestamp(6)) engine=CONNECT table_type=DOS file_name='tc.file'; |
Query OK, 0 rows affected (0.03 sec) |
|
|
MariaDB [test]> insert into tc values ('2012-12-12 12:12:12.123456'); |
Query OK, 1 row affected (0.01 sec)
|
|
|
MariaDB [test]> select * from tc; |
+----------------------------+ |
| t |
|
+----------------------------+ |
| 2012-12-12 12:12:12.000000 |
|
+----------------------------+ |
1 row in set (0.00 sec) |
$ cat data/test/tc.file
|
1355307132
|
As a side-effect, system versioning for CONNECT tables does not work at all.
Attachments
Activity
| Field | Original Value | New Value |
|---|---|---|
| Assignee | Olivier Bertrand [ bertrandop ] |
| issue.field.resolutiondate | 2018-04-22 17:54:52.0 | 2018-04-22 17:54:52.071 |
| Fix Version/s | N/A [ 14700 ] | |
| Fix Version/s | 10.3 [ 22126 ] | |
| Resolution | Not a Bug [ 6 ] | |
| Status | Open [ 1 ] | Closed [ 6 ] |
Looking at the definition of MariaDB's timestamp in https://mariadb.com/kb/en/library/timestamp/ the timestamp format does not have millisecond even if it says Microseconds with a range of 0 to 6 can also be specified. If not specified, 0 is used.
Later on, it says that timestamps are internally stored as Epoch Seconds which cannot store millisecond. This is also what CONNECT does for all date data types.
It seems that later, additional storage was added for milliseconds but CONNECT does not support this.
I don't understand why table system versioning would need milliseconds. This could be another issue: versioning should be available without milliseconds.
| Workflow | MariaDB v3 [ 86706 ] | MariaDB v4 [ 154216 ] |
Works as designed.