Validation on association set

Questions / Help
,
1

I have a registrations model and participants model as follows:

schema "registrations" do
    field :conf_number, :string
    field :status, :integer, default: 1
    belongs_to :event, Event
    has_many :participants, Participant
    timestamps()
  end

schema "participants" do
    field :accommodation_choice, :integer, default: 1
    field :age, :integer
    field :amount_paid, :integer, default: 0
    field :arrival_time, :integer, default: 1
    field :city, :string
    field :conf_number, :integer
    ...
    field :primary, :boolean, default: false
    ...
    field :admin_comment, :string
    belongs_to :registration, Registration
    belongs_to :country, Country
    belongs_to :payment, Payment
    timestamps()
end

I am using nested resources to save the registration with participants. I want to include a validation in changeset that there should be one participant with primary boolean as true while saving the registration. What is the best way to achieve this?

I have create_changeset and changeset (for update) with some logic running but both of them call the following common_changeset in the end:

defp common_changeset(changeset) do
    changeset
    |> validate_required([:conf_number, :event, :status])
    |> cast_assoc(:participants, required: true)
    |> unique_constraint(:conf_number)
end

I want to be able to add something like check_primary method to the common_changeset pipeline as last step. Thanks.

1 Like
2

Would something like that work?

defp common_changeset(changeset) do
    changeset
    |> validate_required([:conf_number, :event, :status])
    |> cast_assoc(:participants, required: true)
    |> unique_constraint(:conf_number)
    |> check_primary()
end

@spec check_primary(Ecto.Changeset.t()) :: Ecto.Changeset.t()
defp check_primary(%{valid: true, changes: %{participants: participants}} = changeset) do
  if Enum.find(participants, fn participant -> participant.primary end) do
    changeset
  else
    add_error(changeset, :participants, "needs to have a primary participant")
  end
end
defp check_primary(changeset), do: changeset
3

@idi527 thanks for the response.

This does not work as it checks only the changeset and not the participants records. It throws error if changeset does not have primary key. Also, there can be possibility that participant records had a primary: true for a specific participant but changeset is carrying primary: false for same participant. Basically, I need to be able to check it over participants records with changeset applied but before persisting the data.

BTW, I changed valid: true to valid?: true in the above code.

4

Then you might look into :data instead of :changes

@spec check_primary(Ecto.Changeset.t()) :: Ecto.Changeset.t()
defp check_primary(%{valid?: true, data: %{participants: participants}} = changeset) do
  if Enum.find(participants, fn participant -> participant.primary end) do
    changeset
  else
    add_error(changeset, :participants, "needs to have a primary participant")
  end
end
defp check_primary(changeset), do: changeset
5

@idi527 changing to data checks for the validation in persisted records but in case the changeset is carrying primary: false, that is not applied and hence, the validation passes even though it should throw an error. How do we apply the changes and then check the records before persisting?

6

Then you can check both :changes and :data. As far as I am aware, :changes will become :data only after some Repo.* call.

7

Checking them separately does not help.

I ran into another situation where I need the changes applied to record - I need to compute fees for the participant but that can happen only after arrival_date and departure_date changes, if any, are applied to the record. Coming from RoR world, Active_record lets you do that in before_save callback. How would that get translated to Ecto?

8

Maybe something like Ecto.Multi might help. It would look like this

alias Ecto.Multi

@spec create_registration(%{binary => term} | %{atom => term}) :: {:ok, %{registration: %Registration{}, check_primary: :ok}} | {:error, :registration | :check_primary, Ecto.Changeset.t | :error, changes_so_far :: %{optional(atom) => term}}
def create_registration(attrs) do
  Multi.new()
  |> Multi.insert(:registration, Registration.changeset(%Registration{}, attrs))
  |> Multi.run(:check_primary, fn %{registration: registration} -> check_primary(registration) end)
  |> Repo.transaction()
end

which would rollback if check_primary(registration) returns :error.

Checking them separately does not help.

Why? I thought it’d work … Can you show the code that you’ve used?

I need to compute fees for the participant but that can happen only after arrival_date and departure_date changes, if any, are applied to the record

That also could be done either in a multi or through a changeset, I prefer changesets:

@spec put_fees(Ecto.Changeset.t) :: Ecto.Changeset.t
defp put_fees(%{valid?: true, changes:%{arrival_date: arrival_date, departure_date: departure_date}} = changeset) do
  put_change(changeset, :fees, compute_fees(arrival_date, departure_date))
end
defp put_fees(changeset), do: changeset
1 Like
9

Solved the first requirement as follows:

@spec check_primary(Ecto.Changeset.t()) :: Ecto.Changeset.t()
defp check_primary(%{valid?: true} = changeset) do
    registration = apply_changes(changeset)
    case Enum.count(registration.participants, fn participant -> participant.primary end) do
        1 -> changeset
        _ -> add_error(changeset, :base, "One primary registrant required")
    end
end

defp check_primary(changeset), do: changeset

not sure if this is the best approach though. @idi527 thanks for all your help.

3 Likes
10

Didn’t know about apply_changes/1. I think it’s a pretty good approach, much better than what I suggested.

11

this will match only if both, arrival_date and departure_date changes. I need to cover the scenarios where either date change will trigger the computation.

Anyway, will use apply_changes for now and complete this as well.

12

this will match only if both, arrival_date and departure_date changes.

I thought that was the requirement …

only after arrival_date and departure_date changes

If a change in either should cause :fees recalculation, you can check

keys = Map.keys(changes)
:arrival_date in keys or :departure_date in keys
13

apologies, was not clear with the requirements.