There will also be a part of the guide that focuses on things you can do before upgrading that will minimize the impact (like making the MyApi.* - Ash.* transition).
zachdaniel
Creator of Ash
1
sevenseacat
Author of Ash Framework
We will be deprecating the functions that we typically on
MyApp.MyApi, in favor of those same functions defined in theAshmodule.
Oh I really like this one too! This will make building generic functionality much easier, eg. the touch_related change I wanted to write - I think I was stuck on how to reliably figure out what API the related resource was in.
3
dblack
I love where 3.0 is heading! One little question. Do you need to configure the domain in the resource, and list all the resources in the domain? Seems like a bit of double handling for the same configuration?
defmodule MyApp.Accounts.User do
use Ash.Resource,
domain: MyApp.Accounts
end
defmodule MyApp.Accounts do
use Ash.Domain
resources do
resource MyApp.Accounts.User
resource MyApp.Accounts.UserToken
# ...
end
end
1
zachdaniel
Creator of Ash
At the moment you do need to do it in both places, yes. This is because some extensions need to know all resources for a given api, and a static list is the only way to do that at compile time.
You will get a warning if the configuration is wrong though, which should prevent it from being a source of bugs, but it is an unfortunately necessary inconvenience.
1
sezaru
Are you still accepting suggestions for changes for Ash 3.0?
Here is something that I was wondering:
Sometimes, I have a resource module that starts getting too busy.
For example, I have resources that has the attributes, postgres, graphql, rbac, policies, actions, etc.
It is great that everything is in one place, but at the same time I do wish that for some cases I would be able to extract some code block and move it into a new module.
For example, something like this:
defmodule MyResource do
use Ash.Resource,
implementations: [MyResource.Postgres, MyResource.Policies]
attributes do
...
end
relationships do
...
end
actions do
...
end
end
defmodule MyResource.Postgres do
use Ash.Resource.Implementation,
data_layer: AshPostgres.DataLayer
postgres do
...
end
end
defmodule MyResource.Policies do
use Ash.Resource.Implementation,
authorizers: [Ash.Policy.Authorizer]
policies do
...
end
end
I wonder if something like this would be possible with Ash 3.0 or if there is some technical or architectural problem blocking it.
0
zachdaniel
Creator of Ash
This is implemented in spark already 
defmodule MyResource do
use Ash.Resource,
fragments: [MyResource.Postgres, MyResource.Policies]
attributes do
...
end
relationships do
...
end
actions do
...
end
end
defmodule MyResource.Postgres do
use Spark.Fragment,
of: Ash.Resource,
data_layer: AshPostgres.DataLayer
postgres do
...
end
end
defmodule MyResource.Policies do
use Spark.Fragment,
of: Ash.Resource,
authorizers: [Ash.Policy.Authorizer]
policies do
...
end
end
12
zachdaniel
Creator of Ash
Feel free to share any ideas you have!
sezaru
sezaru
Here is another idea.
First a disclaimer, I didn’t think too deep about this, so I’m not sure how relevant it is, it is just something that I particularly had problems before.
I was wondering if we could have a more “low level” version of Ash.Query in Ash 3.0.
Basically what I mean by that is having something that is closer to what Ecto.Query has, in other words, having a low level API that is closer to raw sql.
I know that we can get an Ecto.Query from an Ash.Query via the data_layer_query function, but after we transform it into an Ecto.Query we can’t go back, that means that some functionality of Ash is lost (for example, support for pagination).
Another thing that bothered me a little bit is the requirement to create a calculation when trying to sort data via another resource field, for example:
defmodule ResourceA do
attributes do
attribute :score, :decimal
end
end
defmodule ResourceB do
relationships do
belongs_to :resource_a, ResourceA
end
calculations do
calculate :score, :decimal do
calculation expr(resource_a.score)
end
end
end
It would be great if I could just express directly that I want to sort by ResourceA score attribute in ResourceB without having to create that calculation.
0
zachdaniel
Creator of Ash
In terms of providing a low level query/bridging that gap, it is potentially possible. We can explore it, but it wouldn’t be in the near future likely.
As for requiring to create a calculation when sorting on another field, there is a feature that was added recently to allow you to do this without calculations.
|> Ash.Query.sort([:foo, Ash.Query.expr_sort(resource_a.score)])
4