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
Let me try to say clearly what are the steps to upgrade from 7.0.1 to 7.0.2.
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 dodb: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.
Still relevant, added information in my last comment but no reply.
BTW, adding
precision: nil
is not a problem, in the schema in 7.0.1, unless there was a explicitprecision: 6
before, that meantprecision: 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.What would cause a behavior change is:
What is the diff for the table that you saw the behavior change?