I’m migrating a large app from Ecto 2 to Ecto 3. I know that the milliseconds for utc_datetime was deprecated but I’m not sure what the best way to handle that is.
I could go through every instance where a record is created/updated and add DateTime.truncate(utc_datetime, :second) but that seems like a lot of effort and even with a comprehensive test suite I’m worried I’d miss something.
Out of curiosity I just changed a field on the schema to utc_datetime_usec, without running any migrations and the test passed. Could I just update the field/3 on the schemas or should I also write a migration to change the table columns to utc_datetime_usec?
Thanks for the response. This seems to be the easy route for timestamps but we have other fields which are set to utc_datetime I’m wondering what impact would it have if I changed: field(:soft_delete, :utc_datetime) to field(:soft_delete, :utc_datetime_usec)
Like the above article, all of the literature on this seems to be directly related to the timestamps/1 function but not other fields which (for better or worse) are using utc_datetime.
Usually timestamps/1 are mentioned as it’s simply most popular use case. Similarly the most popular examples for has many relation is Blog.Post which has many Blog.Comment. If you understand how one work then you can use that knowledge on other cases (here other fields). timestampts/1 is just a macro which under the hood is generating exactly same field as you would write manually except that there is some extra code under the hood when calling for example Repo.insert/1 and Repo.update/1 functions who simply sets/changes said timestamp fields without a need to be passed by developer.
