Yeah I’m making some assumptions about your User schema cause it isn’t posted here. I’m assuming that if you have a purchase_id then you’d have a belongs_to :purchase, Purchase. If that isn’t true then you’ll need to change the join.
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
2
LostKobrakai
The second element on the tuple will only be a list of values if you explicitly ask for returned values.
1
Fl4m3Ph03n1x
Because of the circumstances in which I am working, changing the schema is not ideal. Therefore I ended up going with the solution I mentioned from Stack Overflow.
However, I will still pick @benwilson512 's solution as the final one in this post, since it is a great solution that would likely be more readable if not for the limitations of my use case.
I would also like to thank everyone that participated in this thread and corrected some of my incorrect beliefs of how the system works. This is how I grow, and I thank everyone for taking the time to point out.
0
benwilson512
Author of Craft GraphQL APIs in Elixir with Absinthe
Notably, you can just write the join out by hand if you have the column and can’t change the schema:
query = from u in Users,
join: p in Purchase, on: p.id == u.purchase_id,
where: p.item_id == ^item_id
2
dimitarvp
(EDIT: Sorry, just now saw you actually know about this. Still, leaving it in).
While I completely support @benwilson512’s recommendation and I feel the same – that PG should be able to handle a humongous DELETE command – I’ll still give you an alternative if you truly feel you want an iterable solution in Elixir. Taking the latter part of your “Stream way” snippet and modifying it:
Repo.transaction(fn ->
stream
|> Stream.chunk_every(1000)
|> Enum.each(fn batch ->
Users
|> where([u], u.purchase_id in ^ids)
|> Repo.delete_all()
end)
end, timeout: :infinity) # or something like two hours?
You are right to be worried that Enum.to_list might crash the VM. If you suspect anything more than 5_000 records, usually it’s not at all recommended to try and get them into memory because e.g. big binaries might stick around and render garbage collecting ineffective while still having a BEAM VM OS process taking a huge amount of RAM.
Thus, use Stream as intended and chew through work at your own pace. You could also do an SQL count query beforehand and have a progress % while you’re deleting the records in batches.
1