zac

Validation that tests relationship value (without using custom validator?)

I feel like there should be an easy way to do this, without creating a (relatively complicated) custom validation. But after combing the docs and forum, I’m thinking perhaps not…

Here’s a somewhat simplified case.

I have two resources, a sprint and an activity.

sprint’s have a date range, e.g., sprint.start_date and sprint.end_date.

Activities belong to sprints, and have a date, activity.date.

def Sprint do
  attributes do
    attribute :start_date, :date, allow_nil? false
    attribute :end_date, :date, allow_nil? false
  end
end

def Activity do
  attributes do
    attribute :date, :date, allow_nil? false
  end

  belongs_to :sprint, Sprint do
    attribute_writable? true
    allow_nil? false
  end
end

The desired outcome is that an activity’s date must fall within the start and end dates of its sprint.

It seems I should be able to do something like the following – but, I haven’t been able to figure out how.

# This absolutely won't even compile, but it expresses the idea I'm after:
validations do
  validate compare(:date, greater_than_or_equal_to: :sprint.start_date)
  validate compare(:date, less_than_or_equal_to: :sprint.end_date)
end

Maybe I’m expecting too much and I need to do a custom validator, but thought I’d post the question. (I’m also just getting back into Ash… just upgraded a small project from 2.4 to 3.4, and really dusting off some very, very dusty recollection of how it all works…)

If there is a way to achieve the above without dropping into complicated (potentially atomic) validations and atomic_ref() and the like… well, I’d love some pointers. Not up to speed on atomics yet… Thanks!

10 comments

/ash #ash-postgres

3 373 10

2024-09-22 15:35:58 UTC

Marked As Solved

zachdaniel

Creator of Ash

The main thing that makes validations across tables like this hard is that, unlike other validations, there is no guarantee that they will be true as the related resource can change on its own. But that doesn’t necessarily have to be a problem, it’s just on you to understand that that is the case.

Unfortunately there is no builtin validation, so you will in fact need to drop down to the complicated version of things. Good thing I’m here!

defmodule ValidateWithinSprintRange do
  use Ash.Resource.Validation

  def atomic(changeset, _, _) do
     {:atomic, 
       
       # the fields involved. Used by the framework (technically its not but it will some day)
       [:start_date, :end_date], 
       
       # the expression that should *not* be true. i.e if this is true, the error will be raised
       expr(^atomic_ref(:date) < sprint.start_date or ^atomic_ref(:date) > sprint.end_date), 
       
       # an expression that calls `error/2` to produce the expression
       expr(
         error(
            Ash.Error.Changes.InvalidAttribute, %{
              field: :date,
              value: ^atomic_ref(:date),
              message: "date must be between the sprint's start and end date"
            }
         )
      )
    }
  end
end

Something along those lines should do the trick. By defining it this way (with only an atomic callback) the validation will always be deferred to when the query is run. But in the case of checking related data, thats typically the time you’d want to do it anyway. What you can do if you want the eager validation, like in a form, is add a regular validate/3 callback that does the same work manually.

I think this can be made much more ergonomic over time, but it’s good to know how to do this

Post #2

Also Liked

zachdaniel

Creator of Ash

validate Something, only_when_valid?: true to run it only when the changes are valid.

The idea is that you may want to provide many validation errors at once instead of just the first one that fails.

For your particular case, you can decide how you want it to behave. On its own it might make sense to just ignore the validation entirely if there is no sprint_id. It’s something else’s job to ensure that it is set.

  def validate(changeset, _, _) do
    if spring_id = Ash.Changeset.get_attribute(changeset, :sprint_id) do
      your_logic
    else
      :ok
    end
  end

Then the experience of the caller would be “you must set spring_id”, and then “must be in range” if it’s not in range.

Post #9

zac

@zachdaniel, while Ash Framework has a bit of a learning curve, as always you’ve thought ahead and built in a great deal of flexibility and power. Looking forward to (again!) getting more familiar with it!

Would love to see some of the above make its way into the docs. While I feel like all the pieces are there, putting it together can be a challenge. Perhaps building out the existing examples with some of these more subtle (and powerful) features would be helpful, especially now with atomics on the scene…

Post #10