larshei

larshei

After doing the Ash Livebook Getting started for several times over the last 2? years,
I finally have a small project that I dare to tackle with Ash.

Loving it so far.

However, sometimes I am not quite sure what to do when receiving an error.

Basic Idea / Context

  1. The system is meant to collect “Proposals”.
  2. Proposals can be handed in, updated, accepted and rejected during a given timespan.
  3. Each given timespan is called a Proposal Round.
  4. All Proposals are related to a Proposal Round. They can only be interacted with while the Proposal Round is active.
  5. The Proposal Round being active is checked in a custom validation

The custom validation

defmodule Validations.OpenForProposals do
  use Ash.Resource.Validation

  @impl true
  # is this how we would properly check the round_id?
  def validate(%{attributes: %{round_id: id}}, _opts, _context) when not is_nil(id) do
    validate_open(id)
  end

  def validate(%{data: %{round_id: id}}, _opts, _context) when not is_nil(id) do
    validate_open(id)
  end

  def validate(_changeset, _opts, _context) do
    {:error, field: :round_id, message: "No proposal round was set."}
  end

  def validate_open(round_id) do
    with {:ok, round} <- Ash.get(Proposal, round_id),
         true <- round.is_open == true do
      IO.puts("OPEN FOR PROPOSALS") # ---- THIS IS PRINTED :) --------
      :ok
    else
      false -> {:error, field: :round_id, message: "Not currently open for proposals."}
      e -> e
    end
  end
end

Domain Module

defmodule Proposals do
  use Ash.Domain

  resources do
    resource Proposal do
      define :propose,
        args: [:employee_id, :round_id, :text],
        action: :propose

      define :accept,
        args: [:comment],
        action: :accept

      define :reject,
        args: [:comment],
        action: :reject
    end
  end
end

Resource Module

defmodule Proposal do
  use Ash.Resource, domain: Proposals, data_layer: AshPostgres.DataLayer

  actions do
    defaults [:read, :destroy, update: :*]

    create :propose do
      accept [:employee_id, :round_id, :text]

      validate {Validations.OpenForProposals, []}
    end

    update :accept do
      accept [:comment]

      validate {Validations.OpenForProposals, []}

      change set_attribute(:status, :accepted)
      change set_attribute(:comment, arg(:comment), set_when_nil?: false)
    end

    update :reject do
      accept [:comment]

      validate {Validations.OpenForProposals, []}

      change set_attribute(:status, :rejected)
      change set_attribute(:comment, arg(:comment), set_when_nil?: false)
    end
  end

  attributes do
    # ...
  end

  relationships do
    # ...
  end

  postgres do
    # ..
  end
end

The error

The current error is the following:

iex> {:ok, proposal} = Proposals.propose(me.id, 1, "Add 5 more chairs to the break room.")
  {:ok,
   #Proposal<
   ...
  >}
iex > Proposals.accept(proposal, "Good idea. Matthew will take care of it.")
  %Ash.Error.framework{
     errors: [
       %Ash.Error.Framework.MustBeAtomic{
         resource: Proposal,
         action: :accept,
         reason: "Validations.OpenForProposals does not implement `atomic/3`",
         splode: Ash.Error,
         bread_crumbs: [],
         vars: [],
         path: [],
         stacktrace: #Splode.Stacktrace<>,
         class: :framework
       }]}

So the validation works on :propose, but not on :accept.

I have read Basic bulk actions, atomics, new stream options, `error/2` expression and Update Actions — ash v3.29.3, but I do not understand what to do or what the error actually means (and why it occurs on the validation?!) :sweat_smile:

What am I not seeing / understanding and where I could I learn about it?

Showing Posts 1 to 7

03juan

03juan

As far as I can tell, in the info block for Fully Atomic Updates it states

An atomic update is one that can be done in a single operation in the data layer. This ensures that there are no issues with concurrent access to the record being updated, and that it is as performant as possible.

Since you’re fetching the record from the data layer and asserting on is_open in validate_open, there could be a race condition between application processes where one reads and acts on what it sees is a valid state in the data layer but before the write happens another process also changed the data so that the first process’s data is actually not valid any more.

So Ash is expecting you to tell it how the update could be done atomically using the atomic/3 callback.

See Validations without an atomic callback a little further down.

I think the first case works because it’s a create action, not an update

zachdaniel

zachdaniel

Creator of Ash

Exactly correct :slight_smile:

If this can’t be done atomically, you can add require_atomic? false to the action definition.

03juan

03juan

This is probably easier to do in the action with present/2

validate present([:round_id])

larshei

larshei OP

Alright, thanks!

in this scenario, race conditions do not really matter, cause all the steps are manual anyway, and the worst thing that could happen is someone submitting a proposal 5 ms after the round is being closed, which is not a big deal.

However, I have to admin I have no idea what I would need to do if race conditions actually mattered :smiley:

03juan

03juan

For that you’d have to figure out how to do a explicit blocking lock on the row, which would run your operation to validate the open status and then update the approval in a transaction. So any other processes are made to wait for the row to unlock before they can go on.

zachdaniel

zachdaniel

Creator of Ash

In Ash, this can be placed in your update action change get_and_lock(:for_update)

03juan

03juan

Beautiful. Love your work!

— All posts loaded —

Where Next? Top

Trending in Questions Top

stjefim
Hello! Suppose you are building workflow (order / task / payment) processing system with the following requirements: Each workflow con...
New
jonnycharles
I’m in search of an Elixir library that offers PDF generation capabilities similar to Ruby’s Prawn. While there have been discussions abo...
New
Blokh
Hey guys, I’ve got a huge CSV ( around 10 GB ) that needs to be processed hourly Do you guys have any suggestions what is the best prac...
New
roeland
Kia ora, We have been using elixir-google-api to connect to Google Drive. However, with the updates to Tesla due to CVEs this is now bro...
New
kszambelanczyk
Hello! Could someone please give me a help/sample code, how to delete a file from s3 using waffle/waffle_ecto from Phoenix app. I creat...
New
subsaharancoder
I’ve followed the Phoenix LiveView file upload code here Uploads — Phoenix LiveView v1.0.0-rc.7 and so far everything works just fine wit...
New
Onor.io
I have what I’ve heard referred to as a “lookup table” in my database. This is a way of assigning codes to common values. One common lo...
New

Other Trending Topics Top

JesseHerrick
Hey, I’m Jesse and I’m the main contributor behind Dexter, a full-featured, lightning-fast Elixir LSP optimized for large codebases. It s...
New
garrison
Hobbes is a low-level distributed database for the Elixir programming language. Hobbes provides a simple, safe, and scalable storage lay...
New
jimsynz
Beam Bots (or just BB for short) is a framework for building fault-tolerant robotics applications in Elixir using familiar OTP patterns. ...
New
mcass19
ExRatatui lets you cook up rich terminal UIs in Elixir, powered by Rust’s ratatui via Rustler NIFs. Build interactive terminal applicatio...
New
netoum
Corex is an accessible, unstyled UI component library for Phoenix that integrates Zag.js state machines using Vanilla JavaScript and Live...
New
Damirados
Hello everyone. After busy few months I am happy to announce v0.1.0 of Emerge &amp; Solve. They are GUI (Emerge) and State management (S...
New

We're in Beta

About us Mission Statement

Options

Thread Display Mode




Thread Preview

Skip Thread Previews