rails: `precision: nil` added to datetime columns in `schema.rb` in 7.0.2 causes a change in value

Steps to reproduce

Running db:migrate in 7.0.2 adds precision: nil to datetime columns using postgres (a change from 7.0.1 discussed here https://github.com/rails/rails/issues/43909).

After this, one of our spec comparing dates is failing because of what looks like a precision related error:

Diff:
       @@ -1 +1 @@
       -Mon, 21 Feb 2022 14:10:49.640199500 CET +01:00
       +Mon, 21 Feb 2022 14:10:49.640199000 CET +01:00

The test basically asserts:

period = create(:period)
user = create(:user, period: period)

expect(period.start_at).to eq(user.period.start_at)

More importantly, this leads me to think there’s an actual precision change that would not be reflected on production, only locally. I’m not sure how to rectify this.

In addition, it’s unclear what nil means in this case. I liked the explicit 6 or no mention for default, but a change to nil was confusing. I assume it stands for the default.

Expected behavior

No DB/value change

Actual behavior

DB change

System configuration

Rails version: 7.0.2.2

Ruby version: 3.0.3

postgres version: 13.4

About this issue

Original URL
State: closed
Created 2 years ago
Reactions: 2
Comments: 34 (18 by maintainers)

Commits related to this issue

Run rails db:migrate against rails 7 Removes precision on timestamps as this is now internally handled by activerecord. see https://github.com/rails/rails/issues/44571#issuecomment-1059295012 for mo... — committed to ministryofjustice/legal-framework-api by jsugarman 2 years ago
add kana to profiles `precision: 6` is removed since Rails 7.0. See https://github.com/rails/rails/issues/44571#issuecomment-1059295012 — committed to cloudnativedaysjp/dreamkast by takaishi 2 years ago
Add rails 7 timestamp precision changes These occur on any rails db:migrate following the upgrade to rails 7. see [issue](https://github.com/rails/rails/issues/44571) which supposedly says precision... — committed to ministryofjustice/laa-apply-for-legal-aid by jsugarman 2 years ago
apply rail migration scheme dump changes In addition to uuid generator explciit schema naming change, `"gen_random_uuid()"`-->`"public.gen_random_uuid()"`, for some reason that is unclear a previousl... — committed to ministryofjustice/laa-apply-for-legal-aid by jsugarman 2 years ago
Include the Rails version in the database schema This is from the "Upgrading Ruby on Rails" guide: https://guides.rubyonrails.org/upgrading_ruby_on_rails.html#rails-version-is-now-included-in-the-ac... — committed to dmarcoux/open-build-service by dmarcoux 2 years ago
Upgrade to Rails 7 Why these changes are being introduced: This is the first step in the Rails 7 upgrade process. Relevant ticket(s): * https://mitlibraries.atlassian.net/browse/ENGX-156 * https:/... — committed to MITLibraries/thing by jazairi a year ago
Fix CURRENT_TIMESTAMP spec. cf. https://github.com/rails/rails/issues/44571 — committed to ridgepole/ridgepole by winebarrel a year ago

Most upvoted comments

Let me try to say clearly what are the steps to upgrade from 7.0.1 to 7.0.2.

# Rails 6.1
bin/rails db:schema:load

# Rails 7.0.2
bin/rails db:schema:dump
# Commit the generated file

If you are already on Rails 7.0.1, unfortunately loading the schema from the schema.rb will give you the wrong database schema, that is why you get timestamp(6) when you do db:prepare in 7.0.1. That was the bug that was fixed on 7.0.2. So it is important to load the schema from a version of Rails that doesn’t have the bug. I’m not sure if that would if you load on 7.0.2, but I believe so.

Unfortunately, the bug on 7.0.0 make this very hard to upgrade, that is why in 7.0.2 the Rails version is bumped in the schema to keep backward compatibility easier to achieve.

I believe the fact you are getting test errors when upgrading to 7.0.2 is because the test was relying in the bug existing in 7.0.1 and that test now should be updated to match the schema generated by 7.0.2, or your schema should be changed by introducing a new migration that would change the precision of the column to what the test is expecting.

rafaelfranca on Sep 14, 2022

Still relevant, added information in my last comment but no reply.

thisismydesign on Jun 21, 2022

BTW, adding precision: nil is not a problem, in the schema in 7.0.1, unless there was a explicit precision: 6 before, that meant precision: nil. This are just explicit in 7.0.2. They should not have any behavior change. So those following lines are equivalent in 7.0.1 and 7.0.2.

# 7.0.1
t.datetime :foo

# 7.0.2
t.datetime :foo, precision: nil

# 7.0.1
t.datetime :foo, precision: 6

# 7.0.2
t.datetime :foo

What would cause a behavior change is:

# 7.0.1
t.datetime :foo, precision: 6

# 7.0.2
t.datetime :foo, precision: nil

What is the diff for the table that you saw the behavior change?

rafaelfranca on Mar 2, 2022