You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
By defining a state machine on a model, I can non longer define a changeset in my model. If I import Ecto.Changeset after I've defined my state machine, things tend to work well again.
== Compilation error on file web/models/invitation.ex ==
** (CompileError) web/models/invitation.ex:77: undefined function cast/3
(stdlib) lists.erl:1338: :lists.foreach/2
(stdlib) erl_eval.erl:670: :erl_eval.do_apply/6
This is the error I get from my own project, not the gist I created above.
Bottom line, I think by aliasing the Ecto.Changeset inside the macro we are changing the way we need to write changesets in our models for non-state changes. To get the import to work again after using the macro, I either have to import Ecto.Changeset again (as in the second example in the gist) or use Changeset.cast(...), Changest.put_change(...), etc.
If there's a way to make that macro less obtrusive to it's surrounding model, that would be useful.
Thanks for this work, btw.
The text was updated successfully, but these errors were encountered:
By defining a state machine on a model, I can non longer define a changeset in my model. If I
import Ecto.Changeset
after I've defined my state machine, things tend to work well again.I've included examples of what should fail and succeed here: https://gist.github.com/davidrichards/694c7eb030c01b17b014cbaea3aad4f1
The error I get is something along the lines of:
This is the error I get from my own project, not the gist I created above.
Bottom line, I think by aliasing the Ecto.Changeset inside the macro we are changing the way we need to write changesets in our models for non-state changes. To get the import to work again after using the macro, I either have to import Ecto.Changeset again (as in the second example in the gist) or use Changeset.cast(...), Changest.put_change(...), etc.
If there's a way to make that macro less obtrusive to it's surrounding model, that would be useful.
Thanks for this work, btw.
The text was updated successfully, but these errors were encountered: