Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
MySQL 5.6 Fractional Seconds #14359
@arthurnn: Thanks. It is really annoying not being able to store milliseconds from a time... Do you know if your patch also takes care about migrations? Right now I'm unable to create a
Yep, you should be able to, look at the migration on the tests in this PR, https://github.com/rails/rails/pull/14359/files#diff-95d3dfc38be7275845454d444b0826f9R678, so you should be able to do:
t.datetime : fetched_at, limit: 6
Note that this causes undesirable rounding behavior on MySQL 5.6 with lower-precision temporal fields.
In 5.5, when you insert
This has undesirable consequences like breaking apps that rely on
Ideally, we'd format the datetime string according to the precision of the datetime field. Provide microseconds, milliseconds, tens of seconds, etc. No more precision than needed.
@jeremy This is breaking our tests on Rails 4.2 like how you described. An
On paper this looks like it should work, but MySQL stores the 23:23:17.xxxxxx as 23:23:18, so the
We're on MySQL 5.6.16, but the column isn't set to store fractional seconds. Was a pain to track down the issue because this causes non-deterministic test failures :(
SELECT `orders`.* FROM `orders` WHERE (`orders`.`charged_on` BETWEEN '2015-02-20 18:35:44.376956' AND '2015-02-20 18:35:44.376957')
which causes test failures for us.
@rafaelfranca looks like 4-2-stable fixed it, but according to this https://github.com/rails/rails/blob/v4.2.0/activerecord/lib/active_record/connection_adapters/mysql2_adapter.rb#L77 the fix should be in 4.2.0 that is on rubygems correct?
You will also need mysql2 gem >= 0.3.12 for DATETIME and >= 0.3.18 for TIME fields. (A bug in argument count caused us to fail to select milliseconds from a TIME field into Ruby Time object prior to the 0.3.18 release).
Common methods in both mysql adapters are should be added to `AbstractMysqlAdapter`, but some methods had been added to `Mysql2Adapter`. (8744632, 0306f82, rails#14359) Some methods already moved from `Mysql2Adapter` to `AbstractMysqlAdapter`. (rails#17601, rails#17998) Common methods in both mysql adapters are remaining only the `explain` method in `Mysql2Adapter`.
Unfortunately it does. Let's consider following usecase. you insert some records, which recieve a created at.
INSERT INTO `recent_contact_requests` (`requester_id`, `requestee_id`, `created_at`, `updated_at`) VALUES (2, 3, '2014-11-23 13:41:38.394797', '2014-11-22 13:41:38.394797') INSERT INTO `recent_contact_requests` (`requester_id`, `requestee_id`, `created_at`, `updated_at`) VALUES (1, 3, '2014-11-24 13:41:38.394797', '2014-11-23 13:41:38.394797') INSERT INTO `recent_contact_requests` (`requester_id`, `requestee_id`, `created_at`, `updated_at`) VALUES (1, 2, '2014-11-22 13:41:38.394797', '2014-11-24 13:41:38.394797')
RecentContactRequest.where('created_at < ?', 100.days.ago)
which will generate the query
SELECT `recent_contact_requests`.* FROM `recent_contact_requests` WHERE (created_at < '2014-11-24 13:41:38.394797')
So you would expect it to return the first 2 records but not the last one, because the it's created is exactly
However this is not what will happen on mysql below 5.6. Below 5.6 all the records will be stored without the microsecond timestamp. So the last record will be stored with
And for the comparison of dates mysql, will just do a lexical comparison. So
I.d.k why, but we experience this behavior on 5.6 either. The timestamps have been truncated on insert.
This implementation of microseconds also ignores the fact, that a a precision was set manually.
You can define the precision of timestamps for db queries by setting
# set date format to have 3 places for microseconds Time::DATE_FORMATS[:db] = '%Y-%m-%d %H:%M:%S.%3N' #fire up a query RecentContactRequest.where('created_at < ?', 100.days.ago)
will result in
SELECT `recent_contact_requests`.* FROM `recent_contact_requests` WHERE (created_at < '2014-11-24 13:41:38.394.394797')
See issue #19223