How to do a custom validation of an attribute?

Ash Forum Ash Questions / Help
,
1

How can I do a custom validation in the following resource to make sure that the attribute use_by_date is today or later but not in the past?

defmodule App.Shop.Product do
  use Ash.Resource, data_layer: Ash.DataLayer.Ets

  attributes do
    uuid_primary_key :id

    attribute :name, :string do
      allow_nil? false
      constraints min_length: 3
    end

    attribute :price, :decimal

    attribute :use_by_date, :date do
      allow_nil? false
    end
  end

  actions do
    defaults [:create, :read]
  end
end
1 Like
2

What you’re looking for is validations. I don’t think our built in validations will do datetime comparisons, but you can do it with a custom validation.

validate {MyApp.Validations.InTheFuture, field: :use_by_date} 

defmodule MyApp.Validations.InTheFuture do
  use Ash.Resource.Validation
  
  def validate(changeset, opts) do
    case Ash.Changeset.fetch_argument_or_change(changeset, opts[:field]) do
      :error ->
         # in this case, they aren't changing the field, or providing an argument by the same name
         :ok

      {:ok, value} ->
        if DateTime.after?(DateTime.utc_now(), value) do
          :ok
        else
           {:error, field: opts[:field], message: "must be in the future"}
        end
    end
  end
end

EDIT: The validations guide is here: Validations — ash v2.15.6

3 Likes
3

For the archive and Google: The code in the resource would look like this.

  attributes do
    # [...]

    attribute :use_by_date, :date do
      allow_nil? false
    end
  end

  validations do
    validate {App.Validations.InTheFuture, field: :use_by_date}
  end
1 Like
4

I had to tackle the same issue today and adapted the code from Ash’s compare() validation to work with Date structs. It has the same behavior, only the accepted argument types changed.

I’m posting it for the record, also it can be easily adapted to work with DateTime instead.

@zachdaniel I was wondering if maybe it would be interesting to cast to the expected data types before running the validations because I think that would allow the built-in compare validation to work with Date and DateTime? I’m not sure what that could imply, so I’m bringing up the idea in case it’s a good one :smile:

EDIT: my bad, seems like the attribute is already cast in the validator. Not sure why using the classic validation with Date.utc_now() wasn’t working then :sweat_smile:

EDIT 2:

# not working (no error added to changeset)
validate compare(:position_end_date, greater_than: Date.utc_today()),
  where: present(:position_end_date),
  message: "cannot be in the past"

# working perfectly
validate {TalentIdeal.Shared.Validators.DateCompare,
          attribute: :position_end_date, greater_than: Date.utc_today()},
          where: present(:position_end_date),
          message: "cannot be in the past"

Comp should support the Date struct so not sure what the issue might be when using the built-in compare, looks like it should work.

Anyway nothing urgent, 3.0 is a much more serious topic :grin:

5

So, not sure why the builtin one wouldn’t be working, but you need to be careful with Date.utc_today() like that. That will be referring to the day your app was compiled :slight_smile:

Make sure to use &Date.utc_today/0

2 Likes