ash v1.24.2 Ash.Engine.Request View Source

Represents an individual request to be processed by the engine.

See new/1 for more information

Link to this section Summary

Link to this section Types

Specs

t() :: %Ash.Engine.Request{
  action: term(),
  action_type: term(),
  actor: term(),
  api: term(),
  async?: term(),
  authorization_filter: term(),
  authorize?: term(),
  authorized?: term(),
  authorizer_state: term(),
  changeset: term(),
  data: term(),
  dependencies_requested: term(),
  dependencies_to_send: term(),
  dependency_data: term(),
  engine_pid: term(),
  error?: term(),
  id: term(),
  name: term(),
  notify?: term(),
  path: term(),
  query: term(),
  resource: term(),
  state: term(),
  strict_check_only?: term(),
  verbose?: term(),
  write_to_data?: term()
}

Link to this section Functions

Link to this function

add_initial_authorizer_state(request)

View Source

Creates a new request.

The field values may be explicit values, or they may be instances of UnresolvedField.

When other requests depend on a value from this request, they will not be sent unless this request has completed its authorization (or this request has been configured not to do authorization). This allows requests to depend on eachother without those requests happening just before a request fails with a forbidden error. These fields are data, query, changeset and authorized?.

A field may not be resolved if the data of a request has been resolved and no other requests depend on that field.

Options:

  • query - The query to be used to fetch data. Used to authorize reads.
  • data - The ultimate goal of a request is to compute the data
  • resource - The primary resource of the request. Used for openeing transactions on creates/updates/destroys
  • changeset - Any changes to be made to the resource. Used to authorize writes.
  • path - The path of the request. This serves as a unique id, and is the way that other requests can refer to this one
  • action_type - The action_type of the request
  • action - The action being performed on the data
  • async? - Whether or not the request can be asynchronous, defaults to true.
  • api - The api module being called
  • name - A human readable name for the request, used when logging/in errors
  • strict_check_only? - If true, authorization will not be allowed to proceed to a runtime check (so it cannot run db queries unless authorization is assured)
  • actor - The actor performing the action, used for authorization
  • authorize? - Wether or not to perform authorization (defaults to true)
  • verbose? - print informational logs (warning, this will be a whole lot of logs)
  • write_to_data? - If set to false, this value is not returned from the initial call to the engine
Link to this function

put_dependency_data(request, dep, value)

View Source
Link to this function

receive_field(request, path, field, value)

View Source
Link to this function

resolve(dependencies \\ [], func)

View Source

Create an unresolved field.

Can have dependencies, which is a list of atoms. All elements before the last comprise the path of a request that is also being processed, like [:data], and the last element is the key of that request that is required. Make sure to pass a list of lists of atoms. The second argument is a map, which contains all the values you requested, at the same path that they were requested.

For example:

resolve([[:data, :query], [:data, :data]], fn %{data: %{query: query, data: data}} ->
  data # This is the data field of the [:data] request
  query # This is the query field of the [:data] request

  {:ok, result}
  # or
  {:error, error}
  # or
  result
end)
Link to this function

resource_notification(request)

View Source
Link to this function

send_field(request, receiver_path, field)

View Source
Link to this function

store_dependency(request, receiver_path, field, internal? \\ false)

View Source
Link to this function

validate_requests(requests)

View Source
Link to this function

wont_receive(request, path, field)

View Source