Closed supernintendo closed 6 years ago
josevalim
commented
6 years ago @supernintendo can you please provide an application that reproduces the error? Cyclic associations are actually fine (and I have them working in a app) so there is something else happening here causing the issue.
supernintendo
commented
6 years ago @josevalim Sure. The project where I'm running into this is closed source, but I'll dig a bit deeper and see if I can provide some source code that reproduces this.
zoldar
commented
6 years ago We have stumbled into the same problem when trying to bump ecto from 2.1.6 to 2.2.x in our project. We managed to nail it down to after_compile_validation calls for associations, like this one https://github.com/elixir-ecto/ecto/blob/master/lib/ecto/association.ex#L458. When we commented out condition clauses for Code.ensure_compiled?(queryable) check for either Has or BelongsTo association type, the deadlock didn't occur. We haven't managed to create a minimal example reproducing this issue though.
jkslyby
commented
6 years ago @supernintendo - I just encountered the exact same issue.
Would you happen to have module attributes that reference one of your other modules on lines 92 or 95 of web/services/home_assessments/export.ex (or anywhere else for that matter)?
If you remove/relocate those references, it should work™.
josevalim
commented
6 years ago If you have a way to reproduce the issue I would love to take a look at it and see if we can improve the error message or similar.
jkslyby
commented
6 years ago @josevalim - I will try to recreate it on a new project sometime soon. For now, here's the gist of what's happening:
defmodule MyApp.ModelA do
schema "model_a" do
has_many :model_bs, MyApp.ModelB
end
@default_preloads = [model_bs: from(b in MyApp.ModelB, order_by: [asc: b.id])]
end
defmodule MyApp.ModelB do
schema "model_b" do
belongs_to :model_a, MyApp.ModelA
end
endIf I reference MyApp.ModelB inside of MyApp.ModelA in a module attribute, this causes the deadlock situation. That being said, it's probably not good to do that anyway.
supernintendo
commented
6 years ago @jkslyby That seems to be what is causing the problem in my case. It appears that an Ecto query set to a module attribute cannot contain a reference to another module it also depends on. Refactoring those queries allowed my application to compile. Thanks!
supernintendo
commented
6 years ago @josevalim Here is an application that reproduces the issue https://github.com/supernintendo/ecto_deadlock_example
josevalim
commented
6 years ago @supernintendo thank you! It makes sense indeed. Queries are not guaranteed to be compile-time safe and it is actually important that we recompile modules when their query sources chance. Moving it to a function is the way to go.
Description
When updating my Ecto version from
2.1.2to2.2.10my application fails to compile due to a deadlock between modules. All of the modules that are responsible for the failure appear to be compiling before the modules they depend on (i.e. associations) have finished compiling.Environment
phoenix_ecto3.2.1Current behavior
My application fails to compile with the following output:
Expected behavior
The modules that depend on
Haas.HomeAssessmentwait for it to compile before compilation, allowing the application to compile successfully.I couldn't find any reports of this issue but I might have missed it so sorry if it has already been reported. Let me know if you need any other information from my end.
Thanks!