Required validation still failing after put_assoc

Jump off point, same problem, but this solution isn’t working for me.

I have a many_to_many association. Even after getting put_assoc right, the error field for that many to many is still there.

This is the IO.inspect result of the changeset

#Ecto.Changeset<
  action: nil,
  changes: %{
    event_id: 1,
    languages: [
      #Ecto.Changeset<
        action: :insert,
        changes: %{id: 1, value: "Cree"},
        errors: [],
        data: #DeAboriginal.Data.Language<>,
        valid?: true
      >,
      #Ecto.Changeset<
        action: :insert,
        changes: %{id: 2, value: "Algonquin"},
        errors: [],
        data: #DeAboriginal.Data.Language<>,
        valid?: true
      >,
      #Ecto.Changeset<
        action: :insert,
        changes: %{id: 3, value: "Miqmaq"},
        errors: [],
        data: #DeAboriginal.Data.Language<>,
        valid?: true
      >,
      #Ecto.Changeset<
        action: :insert,
        changes: %{id: 4, value: "Ojibwe"},
        errors: [],
        data: #DeAboriginal.Data.Language<>,
        valid?: true
      >
    ],
    name: "edede"
  },
  errors: [
    languages: {"is invalid", [validation: :assoc, type: {:array, :map}]}
  ],
  data: #DeAboriginal.Data.Activity<>,
  valid?: false
>

This is the function that generates the above inspect

  def create_activity(attrs \\ %{}) do
    language_map = Enum.map(attrs["languages"],
                          fn x -> x
                                  |> get_language!()
                                  |> fn y -> %{id: y.id, value: y.value} end.()
                          end)

    %Activity{}
    |> Activity.changeset(attrs)
    |> Ecto.Changeset.put_assoc(:languages, language_map)
    |> IO.inspect()
    |> Repo.insert()
    end

And this is the function upstream of the that, which is the :create

  def create(conn, %{
    "activity" => activity,
    "application_id" => application_id,
    "event_id" => event_id,
  }) do

    case Data.create_activity(activity) do
      {:ok, struct} -> conn
       |> put_flash(:info, "#{struct.name} created!")
       |> redirect(to: Routes.application_event_activity_path(conn, :new, application_id, event_id))
    end
  end

This is the :new

  def new(conn, %{
    "application_id" => app_id,
    "event_id" => event_id
  }) do

    changeset = Data.Activity.changeset(%Data.Activity{
      languages: []
    }, %{})

    languages = Data.list_language()
    render(conn, "new.html",
      activity: changeset,
      application_id: app_id,
      event_id: event_id,
      languages: languages
      )
  end

Also is there a comprehensive Ecto guide out there specific with dealing with the relationships? I feel this association stuff all over the place and everyone that writes about it have their own way of working around it.

Hello,
Perhaps, that’s because Activity.changeset has put errors into :languages key. I think you have to remove code related to :languages from that function, because you handle them explicitly.
Also, removing "languages" key from attrs may help.

To follow up on the prev. post: Validations are evaluated immediately when calling the validation function and never revalidated. If at the time of calling Activity.changeset an error is added it’s in there unless you remove it.

Would calling validation functions again remove it or it has to be removed manually at this point?

It has to be removed manually. The changeset has no knowledge is the new validation is supposed to be the same as a previous one and even if it would errors are not linked back to anything.

That was a very enlightening comment actually. I thought reactive validation was a property of the changeset.

All of a sudden some of the practices of using changeset make sense.

Thanks.

I have one more question regarding associations.

The table language is a lookup table and should not be inserted into. I want associations between activity and language to be build against existing rows in the language table.

My problem is that somehow put_assoc function insists on inserting into that table. I stopped this at the DB end using a unique index, but I cannot tell it to use the put_assoc just as a clue for my associative entity/schema.