zachdaniel

Generating Code

Use list_generators to list available generators when available, otherwise mix help. If you have to run generator tasks, pass --yes. Always prefer to use generators as a basis for code generation, and then modify afterwards.

Ash

Use code interfaces on domains to define the contract for calling into Ash resources. See the Code interface guide for more.

After creating or modifying Ash code, run mix ash.codegen <short_name_describing_changes> to ensure any required additional changes are made (like migrations are generated).

zachdaniel

I don't think this answer is necessarily going to convince you in any way to use Ash 😅. But it felt worth explaining how it works.

You don't have to leverage the AshPostgres data layer necessarily. Resources & actions etc. can be leveraged just for their interface tooling, and you can make queries with Ecto manually. Most people, even people who are very picky about their SQL, often end up not doing that because AshPostgres makes smart choices for you that are hard to replicate manually. What this is talking about when I refer to it as an insane thing to support isn't that we generate pathological queries, its the complexity in query building that we take on to

zachdaniel

defmodule Greeting do
  use Ash.Resource
  # This resource has no struct representation
  # and simply contains the action.
  # What makes this better than a function?
  # https://hexdocs.pm/ash/generic-actions.html#why-use-generic-actions
  
  actions do
    action :say_hello, :string do
      argument :to, :string, allow_nil?: false

zachdaniel

defmodule MyApp.Accounts.Checks.Can do
  use Ash.Policy.SimpleCheck

  def describe(_opts) do
    "Check if a user/ actor has permission on a specific resource"
  end

  # @impl true
  def match?(nil, _, _), do: false

zachdaniel

SELECT * FROM users WHERE splines = "reticulated"

zachdaniel

  # CREATE INDEX users_lower_email_idx ON public.users USING btree (lower((email)::text))
  # CREATE INDEX unique_email_com3 ON public.users USING btree (email, id) WHERE (email ~~ '%.com'::citext)
  defp parse_columns_from_index_def(string, using) do
    string
    |> String.trim_leading("CREATE ")
    |> String.trim_leading("UNIQUE ")
    |> String.trim_leading("INDEX ")
    |> String.replace(~r/^[a-zA-Z0-9_\.]+\s/, "")
    |> String.trim_leading("ON ")
    |> String.replace(~r/^[\S]+/, "")

zachdaniel

Mix.install(
  [
    {:ash, "~> 3.0"},
    {:ash_json_api, "~> 1.0"},
    {:plug_cowboy, "~> 2.5"},
    {:open_api_spex, "~> 3.16"}
  ],
  consolidate_protocols: false
)

zachdaniel

```elixir
def macro uuidv7_primary(name , opts \\ []) do
  quote do
    attribute unquote(name), :uuid, Keyword.merge(unquote(opts), [...your_defaults])
  end
end
```

zachdaniel

<!-- livebook:{"persist_outputs":true} -->

# Distribute

## Section

A small toy to show how you might, given a stream, do a "fan out", processing different elements in separate streams. Powered by simple primitives like `Stream.resource` and `spawn_link`.

```elixir
defmodule Distribute do

zachdaniel

What does "no lock-in" mean in the context of Ash

I think a reasonable definition of "no lock-in" is required. To me its the ability to “start making new choices”, not necessarily “you can push a button and remove your ash stuff”. But we'll get to ejecting at the end.

Ash is stateless. You call functions and it follows the instructions defined in the action. It supports "dropping the bottom" out of any given operation, by overriding whatever action Ash was going to take, And it will happily work along side ecto resources (or w/e) that modify the underlying data it works with.

Keeping in mind that Ash does significantly more than just simple data manipulation/crud, lets look at a simple example.