spicychickensauce
I’m in the process of migrating an application over to using ash. I do need to support both postgres and sqlite, as the app can be either deployed on a server or shipped as an android application. (Side note: If I could somehow use postgres in an embedded way like sqlite then I wouldn’t be in this mess. Maybe someone knows how we could run PGlite embedded in Elixir?)
Now I’ve run into a big obstacle: Ash aggregations are not supported in ash_sqlite.
This wouldn’t be that big of an issue if I could use the old ecto code that does the aggregation, however those queries also include a lot of preload queries. And preload queries do not work with ash resources.
So now I have a working ash implementation, but it only works with postgres.
And I have a working ecto implementation, but that only works with ecto modules, not ash resources.
How do I get out of this? I do not want to keep around both ecto models and ash resources.
Can I somehow implement those aggregates manually, such that they work with sqlite?
Can I somehow convert the ash resources into ecto models that support preloads?
Can I contribute to ash_sqlite to implement aggregates? Is that even feasible?
I greatly appreciate any help here, thanks ![]()
Trending in Questions
Other Trending Topics
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #deployment
- #library
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #channels
- #elixirconf
- #exunit
- #discussion
- #code-sync
- #javascript
- #podcasts
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixir-ls
- #blog-post
- #phoenix_html
- #iex
- #graphql
- #genstage
- #ai
- #elixirconf-us
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #metaprogramming
- #security
- #hex










First 8 of 8 Posts
zachdaniel
What kind of aggregates are you using?
spicychickensauce
What kinds are there?
It’s not actually an aggregate, but a calculation that does the aggregate. But the error is quite clear that aggregates aren’t supported with ash_sqlite (it works with ash_postgres):
The calculation is a bit involved, I have this on
tracksandweb_tracks:And on another resource that uses this calculation on it’s relationships:
(Aside, I’m still a beginner ash user, if there is a better way to write that please let me know)
zachdaniel
Got it, yeah so it is a bit unfortunate. The primary issue is that aggregates use lateral joins in postgres and I haven’t had a chance to figure out a good way to support them in
ash_sqliteyet. However, you can do something like:You lose a lot of the goodness unfortunately. You can also make a calculation that uses
calculateand does this in memory when itsash_sqlitefor example:spicychickensauce
Hmm, ok, the fragment approach doesn’t seem too bad. I used a bit of AI help to translate it, seems to work:
Would be nice if I could pass in an
expr()as an argument to a fragment to simplify that last condition to:fragment(".. AND ?", id, expr(...)). However that does not seem to work.Also, I’m wondering, if it works with sqlite if using a subquery instead of a lateral join, could this be how to implement aggregates support in
ash_sqlite?spicychickensauce
Using the fragment approach, would there be any way to reuse that calculation on the related resource?
Probably not, right?
As the one that uses aggregates on those aggregates now becomes very ugly:
I’d really love to solve this at the
ash_sqlitelevel, maybe you can give me some pointers on how I could approach contributing this feature?zachdaniel
Hmm…unfortunately no, probably not. I do think the big win would be figuring out how to model at least simple aggregates in ash_sqlite. I also do recall hearing something about sqlite supporting lateral joins at some point?
spicychickensauce
I took some time to dig into the source code of ash_sqlite and ash_sql, which would have to change significantly.
Unfortunately this is definitely over my head.
There are many lateral joins in ash_sql, and replacing them by correlated sub queries seems really difficult.
For one, ecto doesn’t support correlated subqueries, so fragments would have to be used for them.
Plus, finding the correct join clause for each lateral join will probably be different for each usage of lateral join, requiring proper understanding of each usage.
It really seems like lateral joins are just the right fit for this kind of problem and sqlite not supporting them really makes it painfully difficult.
There is a branch that implements lateral, but Richard is not convinced it is needed.
Maybe you could be the one to convince him?
I mean, ash definitely solves real-world problems, so you might actually be able to sway him?
spicychickensauce
I just saw that turso might be getting lateral joins soon: https://github.com/tursodatabase/turso/pull/4462
Maybe in the future sqlite will be replaced by turso, as it might just become a better sqlite. “Extended
ALTERsupport” and “improved write throughput using MVCC” sounds awesome to me.