How to compose queries?

tellesleandro

Ecto allows to compose a query, like this:

def for_patio(query \\ __MODULE__, %Patio{} = patio) do
  query
  |> join(:inner, [pe], _ in assoc(pe, :patios), as: :patios)
  |> where([patios: p], p.id == ^patio.id)
end

def for_parceiro(query \\ __MODULE__, %Parceiro{} = parceiro, voucher) do
  query
  |> join(:inner, [pe], ape in assoc(pe, :parceiros_precos_estadias),
    as: :parceiros_precos_estadias
  )
  |> where(
    [parceiros_precos_estadias: ape],
    ape.parceiro_id == ^parceiro.id and
      ape.voucher == ^voucher
  )
end

I can query the resource in different ways:

Resource.for_patio(patio) |> Repo.all
Resource.for_parceiro(parceiro, voucher) |> Repo.all
Resource.for_patio(patio) |> Resource.for_parceiro(parceiro, voucher) |> Repo.all

How do I do that using Ash?

9 comments

/ash

0 655 9

2023-10-10 11:54:51 UTC

Showing Posts 1 to 9

Show Best Posts
Show All (oldest first)
Show All (newest first)

zachdaniel

Creator of Ash

You’d use calculations for this:

calculations do
  calculate :for_patio, :boolean, expr(exists(patios, id == ^arg(:id)) do
    argument :id, :uuid, allow_nil?: false
  end

  calculate :for_parceiro, :boolean, expr(exists(parceiros_precos_estadias, parceiro_id == ^arg(:parceiro_id) and voucher == ^arg(:voucher)))
end

And then you can query like

query =
  Resource
  |> Ash.Query.filter(for_parceiro(parceiro_id: parceiro_id, voucher: voucher))

# or 

query =
  Resource
  |> Ash.Query.filter(for_patio(patio_id: patio_id))

# or combine them

query =
  Resource
  |> Ash.Query.filter(for_parceiro(parceiro_id: parceiro_id, voucher: voucher) and for_patio(patio_id: patio_id))

# they can also be combined in ways you can't combine your example

query =
  Resource
  |> Ash.Query.filter(for_parceiro(parceiro_id: parceiro_id, voucher: voucher) or for_patio(patio_id: patio_id))

You cold then call a code interface and provide this query

YourResource.read(..., query: query)

Or use the underlying api for it

YourResource
|> Ash.Query.filter(....)
|> YourApi.read!()

Post #1

zachdaniel

Creator of Ash

You can also just let the caller filter

Query
|> Ash.Query.filter(exists(patios, id == patio_id))
|> Ash.Query.filter(exists(parceiros_precos_estadias, parceiro_id == ^parciero_id and voucher == ^voucher))
|> YourApi.read()

this is safe to let them do, because all logic ultimately goes through a read action, and is always run through your policies for access rules.

Post #2

tellesleandro

Thanks @zachdaniel. With all this explanation I can move on. I think I get stucked 'cause I feel I have to put all queries inside actions. As far as I can see, it’s not true. Many examples you give show queries that don’t rely on actions, right? In this case, should I create a regular module and put there the queries inside regular functions?

Post #3

zachdaniel

Creator of Ash

Honestly it just depends on how you’re using it. For instance, if you’ve got a live view somewhere, you can do this:

assign(socket, :published_posts, Post.published!())

But you can also do

assign(socket, :published_posts, Post.read!(query: Ash.Query.filter(published == true))

If you are considering making a module somewhere with functions like:

def published_posts do
  Post.read!(query: Ash.Query.filter(published == true)
end

Then at that point I would suggest making it an action, i.e

read :published do
  filter expr(published == true)
end

If you need caller-level composition, then calculations are a good choice.

I know it would be nice if there was “one right answer” but in these case it often comes down to what kind of interface you would need. The general rule of thumb though is: when in doubt, put stuff in an action that does specifically what you need.

Post #4

tellesleandro

Great. I’ll follow these advices. Thanks.

Post #5

zachdaniel

Creator of Ash

No problem I appreciate your questions, and I while we definitely want to improve the documentation, having these kinds of questions here in the forum will help other people when they have similar questions. Documentation improvements are a longer term type thing, but this will help people in the short term

Post #6

tellesleandro

Sure. I hope more devs jump into Ash’s world and take advantage of it. These newbie’ questions may help them too.

Post #7

yasoob

Hey @tellesleandro i just wanna say that your questions and the ensuing discussion is very helpful for newbies like me. Thanks for asking these questions!

Post #8

tellesleandro

Welcome @yasoob. I’m developing real world application for real world customers, not only CRUD examples. So, expect to find more and more newbie questions from me here.

Post #9

— All posts loaded —