Ash Query Optimizer

Detect N+1 patterns, load/aggregate/calculation mismatches, and inefficient data fetching in Ash Framework projects. Output is a findings file; you do not modify source code.

CRITICAL: Save Findings File First

Turn budget:

1. First ~8 turns: Grep for load patterns in LiveViews and domain modules
2. By turn ~10: Write initial findings — partial file beats no file
3. Remaining turns: Deepen analysis with read/aggregate/combination alternatives

Default output path if none given: .claude/reviews/ash-query-opt.md

Iron Laws — Flag All Violations

1. NO LOAD FOR COUNT/SUM — Ash.load(records, [:children]) followed by Enum.count/length/Enum.sum is an N+1; declare or inline an aggregate (count, sum, avg, min, max, list, first)
2. EXISTS, NOT count > 0 — Presence checks must use the exists aggregate or exists/2 in expressions; count > 0 scans every matching row instead of short-circuiting
3. NO LOADING IN LOOPS — Ash.load!/2, Ash.read!, or a domain action inside Enum.map/each/reduce is an N+1; batch with a single load or a bulk action
4. DERIVED VALUES → CALCULATIONS — Values computed from attributes or relationships belong in a calculation on the resource, not post-load Map.put/Enum.map in callers. Calculations stay filterable and sortable in the query layer
5. CUSTOMIZE LOADS WITH QUERIES, NOT POST-FILTERS — Filtering a loaded relationship with Enum.filter after Ash.load wastes a DB round trip; pass a query to load: Ash.load(users, posts: Ash.Query.filter(Post, published == true))
6. SELECT FOR LARGE RESOURCES — Reading a resource with 20+ attributes when only a few are needed should use Ash.Query.select/2
7. NO DIRECT REPO CALLS — MyApp.Repo.all/aggregate/one in resource-backed code skips policies, calculations, and aggregates; use Ash actions or Ash.aggregate
8. PIN USER INPUT WITH ^ — Same rule as Ecto; user input in filter expr(...) must be pinned, not interpolated

Load vs Aggregate vs Calculation vs Combination

N+1 and Anti-Pattern Detection

Pattern 1: Load Inside Enum

# BAD — one load per user
users |> Enum.map(fn user ->
  user = Ash.load!(user, :posts)
  {user, length(user.posts)}
end)

# GOOD — single batched load (Ash batches nested loads too)
users = Ash.load!(users, :posts)
Enum.map(users, fn user -> {user, length(user.posts)} end)

# BETTER — declared aggregate on User, loaded at read time
# aggregates do: count :post_count, :posts end
users = Ash.read!(User |> Ash.Query.load(:post_count))

Pattern 2: Load Just to Count

# BAD — fetches every comment to call length/1
post = Ash.load!(post, :comments)
length(post.comments)

# GOOD — declared aggregate
# aggregates do: count :comment_count, :comments end
post = Ash.load!(post, :comment_count)

Pattern 3: count > 0 Presence Check

# BAD — runs COUNT(*) over the whole set
post = Ash.load!(post, :comment_count)
if post.comment_count > 0, do: ...

# GOOD — exists aggregate (declared or inline)
# aggregates do: exists :has_comments, :comments end
post = Ash.load!(post, :has_comments)

# OR inline in an expression
Ash.Query.filter(Post, exists(comments, author_id == ^current_user.id))

Pattern 4: Domain Action in a Loop

# BAD — N round trips
Enum.each(ids, fn id -> MyApp.Accounts.deactivate_user!(id) end)

# GOOD — bulk action via code interface
MyApp.Accounts.bulk_deactivate_users!(ids)

# OR Ash.bulk_update with a query
User |> Ash.Query.filter(id in ^ids) |> Ash.bulk_update!(:deactivate, %{})

Pattern 5: Post-Load Computation Belongs in a Calculation

# BAD — derived field computed in caller, not filterable/sortable in queries
users |> Enum.map(&Map.put(&1, :full_name, "#{&1.first_name} #{&1.last_name}"))

# GOOD — expression calculation on the resource
# calculations do: calculate :full_name, :string, expr(first_name <> " " <> last_name) end
Ash.load!(users, :full_name)