1.7.33.0-rc.0postgrex 0.14.0-rc.1Unable to upgrade to elixir 3.0-rc due to the date types being removed and timex_ecto relying directly on those type at compile time. Trying to run my app results in:
==> timex_ecto
Compiling 8 files (.ex)
== Compilation error in file lib/types/date.ex ==
** (CompileError) lib/types/date.ex:58: Ecto.Date.__struct__/0 is undefined, cannot expand struct Ecto.Date
lib/types/date.ex:58: (module)
could not compile dependency :timex_ecto, "mix compile" failed. You can recompile this dependency with "mix deps.compile timex_ecto", update it with "mix deps.update timex_ecto" or clean it with "mix deps.clean timex_ecto"
My deps:
defp deps do
[
{:hashids, "~> 2.0"},
{:ecto_sql, "~> 3.0-rc", override: true},
{:ecto, "~> 3.0-rc", override: true},
{:postgrex, "~> 0.14.0-rc"},
{:timex, "~> 3.4"},
{:timex_ecto, "~> 3.3"}
]
end
Should be able to compile with ecto 3.0-rc
Hi @kurtome, there's nothing we can do about this here given Ecto.Date and other types were deprecated in Ecto v2.2 and removed in 3.0 and it's timex_ecto that can't compile so the issue should be opened there.
There's probably less of a need of timex_ecto anyway as both Ecto & Timex use Elixir calendar types underneath.
Right. Those types were removed and it is one of the few breaking changes in Ecto 3, so dependencies will have to act accordingly.
Therefore, please open up an issue in timex_ecto but, as @wojtekmach said, it is most likely you don't need timex_ecto anyway. The maintainers of that project will be able to guide you accordingly.
Got it, thanks for the quick response, I'll follow up on the timex_ecto repo.
Regarding the necessity of Timex, my understanding was that the Elixir primitives for dates and times were pretty lacking and as such it was preferable to simply always speak in Timex types (similar to JodaTime in Java before Java 8 came out). But maybe I'm wrong on that front :)
@kurtome to clarify, you probably still need timex, but you likely do not need the timex_ecto dependency in particular.
@josevalim
I like timex_ecto because it accepts a datetime value with time zone.
Could you elaborate how I can smoothly remove timex_ecto dependency from an app that deals with time zones?
For example, I have this module definition:
defmodule MyApp.Schedule.Item do
use Ecto.Schema
use Timex.Ecto.Timestamps
schema "items" do
field(:name, :string)
field(:starts_at, Timex.Ecto.DateTime)
end
end
I used to write like this in the priv/repo/seeds.exs:
time0 = Timex.now("Asia/Tokyo") |> Timex.beginning_of_day()
insert!(%MyApp.Schedule.Item{
name: "Example",
starts_at: Timex.shift(time0, days: 1, hours: 10)
})
After removing timex_ecto, I rewrote the MyApp.Schedule.Item module as follows:
defmodule MyApp.Schedule.Item do
use Ecto.Schema
schema "items" do
field(:name, :string)
field(:starts_at, :utc_datetime)
end
end
Then, the priv/repo/seeds.exs came to cause this error:
** (ArgumentError) :utc_datetime expects the time zone to be "Etc/UTC", got `#DateTime<2018-11-03 11:00:00+09:00 JST Asia/Tokyo>`
Of course, to fix this error I can rewrite the script like this:
time0 =
Timex.now("Asia/Tokyo")
|> Timex.beginning_of_day()
|> Timex.Timezone.convert("Etc/UTC")
insert!(%MyApp.Schedule.Item{
name: "Example",
starts_at: Timex.shift(time0, days: 1, hours: 10)
})
But, I think such a change is a little burdensome, because my app has quite a lot similar expressions.
Do you have any idea how to upgrade my app to Ecto 3.0 with ease?
I can see how this can be burdensome but perhaps it's worth mentioning that such automatic conversion may lead to subtle bugs:
now = Timex.now("Asia/Tokyo")
Repo.insert!(%Item{starts_at: now}).hour != now.hour # because time is stored in UTC in the DB
so arguably it's a good thing we're forced to be explicit.
A potential solution is to implement custom Ecto type that will make this conversion:
defmodule MyApp.DateTime do
@behavior Ecto.Type
# see: https://github.com/bitwalker/timex_ecto/blob/master/lib/types/datetime.ex
end
I'd advise to start a discussion on http://elixirforum.com etc where a broader community can help out with this.
@wojtekmach
After submitting this comment and one night sleep, I have reached a similar conclusion as yours.
I'll go to Elixir Forum.
Thanks a lot.
I have posted a question on Elixir Forum.
https://elixirforum.com/t/how-to-upgrade-an-app-using-timex-ecto-to-phoenix-1-4-and-ecto-3-0/17676
Most helpful comment
@kurtome to clarify, you probably still need
timex, but you likely do not need thetimex_ectodependency in particular.