Then there’s no time to refactor the database schema. I always encourage people to not half-ass the database design. Do it properly from the get go. It’s like in sports. If you lack the fundamentals, it’s very hard to compensate afterwards.
krasenyp
Schultzer
It depends Ash can’t do everything and you will eventually have to write SQL, I never worked on a project that never had to do that at somepoint. I’m looking forward to tackle migrations next as thats when are going to take a fresh look at what a Ecto.Schema or Ash.Resource is in the world of a relational database is, as we can do things they have a harder time doing.
Most DSLs ends up being tightly coupled. In SQL we flip it upside down. You have access to the whole row when transforming in Elixir and SQL queries stays in the database.
Although we still got some ways to reduce verbosity, but hopefully thats where the community will chime in with better ideas then I have, I’m more of a lets get the engineering fundamentals right, then everything else becomes easy to build on top of.
3
pjode
I definitely agree with the sentiment but I’d be careful not to confuse design w/ implementation. The design decision was sub-typing, single table vs many tables is implementation. “No time to refactor” holds true in the other direction; if you over complicate things, you’ll be stuck with it. That’s why I said “when starting new projects”, alluding to not knowing exactly what’s necessary. May end up with only 3 sub-type specific columns and no sub-type specific relations. I don’t want to hijack the thread though as this is off-topic from the original post because I agree with what you said
Edit: some clarifications
0
jdiago
This is one way I’ve tried that seems convenient in ecto. In the todo list example, it would look something like this:
schema "items" do
field :description, :string
# join with either a join schema or just a raw join table
many_to_many :lists, Todo.List, join_through: Todo.ListItem
many_to_many :projects, Todo.Project, join_through: "projects_items"
field :itemable, :map, virtual: true
timestamps(type: :utc_datetime)
end
schema "lists" do
field :title, :string
many_to_many :items, Todo.Items.Item, join_through: Todo.ListItem
timestamps(type: :utc_datetime)
end
schema "projects" do
field :name, :string
many_to_many :items, Todo.Items.Item, join_through: "projects_items"
timestamps(type: :utc_datetime)
end
In a page that lists all items, I do this:
# context functions
def get_items_with_itemable do
Item
|> Repo.all()
|> Repo.preload([:lists, :projects])
|> Enum.map(&add_itemable/1)
end
defp add_itemable(nil), do: nil
defp add_itemable(%Item{} = item) do
Map.put(item, :itemable, get_itemable(item))
end
defp get_itemable(%Item{} = item) do
list = List.first(item.lists)
project = List.first(item.projects)
list || project
end
# live view
def render(assigns) do
~H"""
<Layouts.app flash={@flash}>
<ul>
<li :for={i <- @items}>
{"#{display_itemable(i.itemable)} - #{i.description}"}
</li>
</ul>
</Layouts.app>
"""
end
defp display_itemable(%Todo.List{title: title}), do: title
defp display_itemable(%Todo.Project{name: name}), do: name
defp display_itemable(_), do: ""
0
PaleWatcher
Thanks everyone for the responses!
Context / why I asked
While learning Ecto / Phoenix / LiveView, I ran into this modeling dilemma and was trying to understand the different layers at the same time.
Before the full mental model was really in place, I was jumping between different layers due to the learning process.
Why I didn’t immediately propose my own solution
I also explored the direction linked by LostKobrakai earlier (separate types, separate structures), but what held me back was:
- at the database level, I modeled this using composite-key / multi-field identity approaches
- in Ecto, this is not really supported in a native or idiomatic way
- so it wasn’t clear to me whether this approach is actually considered idiomatic in an Ecto context
Ecto vs data modeling
What I found interesting is that Ecto + LiveView changesets work really well together, especially for dynamic forms.
If I completely drop Ecto, I don’t just lose an ORM, but also a very useful validation + UI integration layer.
At the same time, it became increasingly clear to me that the database model and the Ecto schema are not the same thing.
At the database level, you can have a perfectly valid relational model (e.g. composite-key / subtype-style structure), which Ecto doesn’t necessarily map in a natural way.
Concrete example (simplified)
schema "items" do
field :type, Ecto.Enum, values: [:item_one, :item_two]
has_one :item_one
has_one :item_two
end
And the more specific schemas:
@primary_key {:id, :id, autogenerate: false}
schema "item_one" do
field :type, Ecto.Enum, values: [:item_one], default: :item_one
belongs_to :item, Item
end
@primary_key {:id, :id, autogenerate: false}
schema "item_two" do
field :type, Ecto.Enum, values: [:item_two], default: :item_two
belongs_to :item, Item
end
This is a really interesting approach — I find the idea of abstracting the association into a single “slot” quite compelling, especially as the number of possible underlying tables grows.
In my case the domain already tends toward multiple item types, so avoiding a growing number of empty or optional has_one associations is exactly the kind of problem I was running into.
0
zachdaniel
Creator of Ash
Schultzer
Most of my thoughts has been that we have always done things where we try to create a DSL to support multiple datastore, instead of embracing the language that already is there. SQL can be first class, adaptable and specialized at the same time. Elixir is uniquely positioned as it is extensible and you can implement foreign language integration with ease, something I’ve never seen done in other languages, which might be why we’ve been dealing with ORMs for over thirty years. Maybe it’s time to think differently?
1
zachdaniel
Creator of Ash
Ash isn’t strictly speaking an ORM although it does quack like that duck for most applications using it 
If all we’re talking about is running queries and getting their results in Elixir structs and that’s the most that you want out of a given tool then its a different discussion, but with Ash we’re much more concerned with generalized modeling problems, or application building primitives and running SQL queries is just “one way” you might do that.
Some examples:
policies do
policy action_type(:read) do
authorize_if expr(public == true)
end
end
If you had a policy like this, Ash will lower it into SQL when running the query:
Ash.read!(Resource)
#=> SELECT * FROM "table" WHERE public = TRUE
But you can also leverage that policy for a lot more things. For example, you can ask for a policy flow chart to hand over for a security audit. Or you can evaluate the policy in memory:
Ash.can?(Resource, :read, %User{},
data: %Resource{public: false},
reuse_values?: true # use the values we have in memory
)
In which case Ash will run the given expression in memory.
Or, for example, the following validation:
update :increment_score do
argument :amount, :integer, default: 1
change atomic_update(:score, expr(score + ^arg(:amount)))
validate compare(:score, less_than: 100)
end
When you run this action, you will get SQL like this:
UPDATE things
SET
id = CASE WHEN
score + {amount} > 100 THEN
ash_raise_error(...) -- We raise an equivalent error
ELSE
id
END
score = score + {amount}
WHERE id = {id}
AND public = true -- policies embedded into queries
Ash is far more than an ORM these are just some examples of that (and likely not really the best ones).
In every non-trivial application I’ve ever worked with ultimately your business logic crosses multiple systems, or multiple queries etc. that must be operated on in concert.
If composition is limited to statements to a data layer, you’re constrained by the capabilities of that data layer. Likewise what Ash brings to the table primarily has to do with a whole suite of intelligent composition that may result in many queries, or even zero queries when running actions.
Even with that in mind my question was more about what concrete limitations you see in Ash that could be otherwise addressed by something more SQL-native as it could easily represent gaps in Ash. With that said, Ash isn’t intended to replace all interaction with a database, it’s about your domain logic. This is perfectly valid Ash code:
action :list_users, {:array, :struct} do
constraints items: [instance_of: __MODULE__]
run fn input, _ ->
result =
~SQL[from users select *]
|> SQL.map(fn row -> struct(User, row) end)
|> Enum.to_list()
{:ok, result}
end
end
1
Schultzer
No doubt that Ash is more then an ORM, the reason why I mentioned Ash was mostly due to the work around automated migration which Ecto is lacking.
The biggest issues I find with traditional ORMs and DSLs in general is lack of precision. I believe that the abstraction is done at the wrong level, which ends up causing more complexity and issues overtime, as the abstraction leaks.
0
zachdaniel
Creator of Ash
To me it’s ultimately about progressive complexity adoption. i.e “precision” is just one of many attributes of any given implementation of a solution to a problem, one that doesn’t always have to be at 10. i.e if you have this:
defmodule SomeResource do
...
actions do
read :read
end
end
You can Ash.read!(SomeResource), but there is no control in Ash anywhere for the order in which you select fields. Technically something out of your control that would make a more specific SQL query in any given case, but no one has ever asked for that feature because its never mattered. My general pattern is to build for the most common cases where the thing or things you are doing can be done hundreds of different ways, but none of them meaningfully better or worse than the others. then if you realize “this SQL query performs bad!” you get escape hatches to then opt into the more specific version of it (like the action I showed above).
On the Ecto lacking migration generation feature, I think it’s possible that it could make sense at that level, but personally I feel that is the job of something that sits higher up in the stack like Ash. Ash benefits from a wonderfully open ecosystem supported by ecto/phoenix (and also packages like yours!) but the more opinionated they get, the harder it actually gets for me to build a high quality abstraction on top of them. i.e Ash does magic to track custom statements, custom identities, unique indexes etc. none of which are modeled by Ecto schemas (which is why Jose didn’t add it if I recall that conversation correctly).
Regardless, I’m interested in other ways of doing things especially if they surface unique options that can’t be provided by Ash or unique benefits. One major one of SQL that I’m sure Ash is nowhere near on is things like individual query performance. We have a bunch of performance enhancements for applications “in general” that are mostly transparent to users (i.e the automatic translation of “get and update” style queries to single “update” queries whenever possible. But I’d be willing to bet a SQL query is faster than an Ash action that gets to a SQL query by a factor of like…100 lol. I’ll optimize the internals pretty heavily after 4.0 but even still it will probably never even be close.
1