MySQL 5.6 and later supports microsecond precision in datetime.

[miyagawa]

MySQL 5.6 supports microsecond fraction with datetime functions: http://dev.mysql.com/doc/refman/5.6/en/fractional-seconds.html

This patch allows saving microseconds to mysql's datetime columns such asupdated_at. This is significant to take benefits from cache_key second precision updated to nanoseconds.

You might want to branch it to include this only for 5.6, but passing these values to < 5.6 doesn't cause issues either, based on my experiment.

See also a pull request on mysql2 gem that addresses retrieving microseconds from mysql to inflate to Time with typecasting enabled.

[jeremy]

Nice! How about a test case to demonstrate microsecond precision?

[sodabrew]

According to http://dev.mysql.com/doc/refman/5.0/en/datetime.html it is safe to provide the microseconds without checking the mysql version. This also works correctly even if strict checking is enabled. Only requirement is that microseconds are 6 decimal places or less (@miyagawa's patch is correct for this).

A DATETIME or TIMESTAMP value can include a trailing fractional seconds part in up to microseconds (6 digits) precision. Although this fractional part is recognized, it is discarded from values stored into DATETIME or TIMESTAMP columns. For information about fractional seconds support in MySQL, see Section 11.1.5.6, “Fractional Seconds in Time Values”.

mysql> select @@sql_mode;
+------------------------------------------------------------------------------------------------------------------------------------------------------+
| @@sql_mode                                                                                                                                           |
+------------------------------------------------------------------------------------------------------------------------------------------------------+
| STRICT_TRANS_TABLES,STRICT_ALL_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,TRADITIONAL,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION |
+------------------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set (0.00 sec)

mysql> insert into mysql2_test (date_time_test) values ('2012-12-12 12:12:12.123456789000');
ERROR 1292 (22007): Incorrect datetime value: '2012-12-12 12:12:12.123456789000' for column 'date_time_test' at row 1
mysql> insert into mysql2_test (date_time_test) values ('2012-12-12 12:12:12.123456');
Query OK, 1 row affected (0.00 sec)

mysql> select date_time_test from mysql2_test;
+---------------------+
| date_time_test      |
+---------------------+
| 2012-12-12 12:12:12 |
+---------------------+
1 row in set (0.00 sec)

mysql> select @@version;
+-----------+
| @@version |
+-----------+
| 5.5.28    |
+-----------+
1 row in set (0.00 sec)

[chadmoone]

+1.

Anything that can be done to help here?

I would be happy to help write a test case, but since the dev box is running MySQL 5.5.29 at the moment, the case would not pass there.

[sodabrew]

If there's a way to require that Travis uses MySQL 5.6, then we can add that to the Rails matrix and write a test that checks for microseconds when running on 5.6. The fact that it works at all indicates that the change does not cause a problem, but does not indicate that the change does work as intended yet.

According to Travis, there's only Mysql 5.5: http://about.travis-ci.org/docs/user/ci-environment/#Data-Stores

Also we haven't provided a stable release of mysql2 that passes microseconds through, that'll be a prerequisite for tests.

[tpendragon]

Any status on this? We're pretty stuck to MySQL, but caching becomes a bother when my cache keys don't have better precision.

[sodabrew]

Rails is now using mysql 0.3.12+, so the microsecond precision is available in the library. There's no MySQL 5.6 on Travis though, so any tests would have to be trusted from local testers at the moment.

[tpendragon]

To get this all the way there I think we'd need precision support in MySQL migrations as well - something not too unlike 96ce1f2 .

[svasva]

any update on this?

[hsbt]

@amatsuda ping

[rafaelfranca]

Merged in at #14359

[arthurnn]

Thanks a lot for the patch. We merged your commit on #14359 .