It appears that as of version 4 the `db:test:prepare` task no longer depends on the `abort_if_pending_migrations` task, which leaves this comment out of sync.
rather than calling methods on the controller. We should test the
values returned by the controller rather than assuming that the
internals are implemented in a certain way.
I'm making this change so that I can construct response objects that
*don't* have the default headers applied. For example, I would like to
construct a response object from the return value of a controller.
If you need to construct a response object with the default headers,
then please use the alternate constructor:
`ActionDispatch::Response.create`
It doesn't make sense to access the response object before a request is
made (how was a response object created without making a request?) This
commit splits testing default headers and default header mutation tests
and removes access to the pre-request response object.
When the response object is `to_a`'d, that means it's been written to
the socket. It doesn't make sense to mutate the response object after
it's been written (and this may raise an exception in the future).
When I originally reviewed the #20317, I believe these changes were
present, but it appears that it was later updated so that they were
removed. Since Travis hadn't re-run the build, this slipped through.
And we are passing them as separate types in the query, which means 0
precision is still not supported by older versions of MySQL. I also
missed a handful of other cases where they need to be conditionally
applied.
Specifically, versions of MySQL prior to 5.6 do not support this, which
is what's used on Travis by default. The method `mysql_56?` appeared to
only ever be used to conditionally apply subsecond precision, so I've
generalized it and used it more liberally.
This should fix the test failures caused by #20317
Timestamp column can have less precision than ruby timestamp
In result in how big a fraction of a second can be stored in the
database.
m = Model.create!
m.created_at.usec == m.reload.created_at.usec
# => false
# due to different seconds precision in Time.now and database column
If the precision is low enough, (mysql default is 0, so it is always low
enough by default) the value changes when model is reloaded from the
database. This patch fixes that issue ensuring that any timestamp
assigned as an attribute is converted to column precision under the
attribute.
This argument was needen when `sanitize_sql_for_conditions` internally
called `sanitize_sql_hash_for_conditions`.
But `sanitize_sql_hash_for_conditions` was deprecated
(eb921000a1)
and deleted
(3a59dd2123)
(4bd089f1d9).
Kasper Timm Hansen