katafrakt
By default Phoenix generators, when creating an Ecto schema, puts a schema definition there (obviously) and a changeset function. I wonder what else do you put in your schema modules and what unwritten rules do you have for that.
I sometimes add functions that somewhat hide the details of underlying data storage, especially in regards to optional associations or weird choices (I have a DB where some boolean fields are represented C-style as 0 or 1 integers, for example).
def premium_package_name(user) do
case user.premium_package do
nil -> nil
package -> package.name
end
end
# or
def finished?(session) do
case session.is_finished do
0 -> false
1 -> true
end
end
I try not to put much more in schemas and keep them relatively minimal.
However, I know some people put functions returning Ecto queries there. I’m not a fan of that. It feel weird that a schema needs to know how it will be queried. But on the other hand I cannot totally reject this approach. If we treat schema module as the place that hides database complexity form the outside world, putting a query there (for which you need to know the database intricacies) makes some sense.
def latest_by_user(user_id, limit \\ 10) do
from(o in Order, where: o.user_id == ^user_id, order_by: [desc: o.created_at], limit: limit)
end
Maybe someone thinks changeset does not belong in schema? That would be an interesting discussion… So what would I find in your schema modules and why? 
Where Next?
Trending in Discussions
Other Trending Topics
Latest Phoenix Threads
Latest on Elixir Forum
Sponsor Spotlight
Master modern tools, write cleaner code, and tackle real-world challenges with Manning books, videos, and courses. Start building today.
Categories:
Sub Categories:
Forums
Popular Tags
- #ecto
- #liveview
- #troubleshooting
- #learning-elixir
- #library
- #deployment
- #erlang
- #testing
- #genserver
- #mix
- #absinthe
- #remote-other
- #otp
- #plug
- #how-to-question
- #macros
- #postgres
- #elixirconf
- #channels
- #exunit
- #discussion
- #code-sync
- #podcasts
- #javascript
- #onsite
- #dialyzer
- #docker
- #authentication
- #umbrella
- #full-time-contract
- #podcasts-by-brainlid
- #ecto-query
- #elixirconf-us
- #blog-post
- #elixir-ls
- #ai
- #phoenix_html
- #iex
- #graphql
- #genstage
- #websockets
- #supervisor
- #advent-of-code
- #distillery
- #processes
- #api
- #forms
- #hex
- #security
- #metaprogramming
Our Sponsors
Build Elixir applications with speed and confidence.
Supporting innovation across the BEAM ecosystem.
We build reliable cloud platforms for business-critical systems.
Catch errors, track performance, monitor hosts and more.
Elixir, Erlang & BEAM conferences from Code Sync - join us in 2026!
Master modern tools, write cleaner code, and tackle real-world challenges.
Bringing learning, work and compliance together since 1987.
Producing high quality Elixir screencasts since 2017.
The team behind Membrane, Popcorn, LiveDebugger. Available for hire.
Courses that'll move you from confusion to "Aha, now I get it!"
Showing Posts 1 to 10- Show Best Posts
- Show All (oldest first)
- Show All (newest first)
dimitarvp
That’s how I treat them, yes. If not for them I might as well write raw SQL so why not put all the SQL-like stuff in there? And if not, where else?
One example: random-generated data you need for security f.ex.
put_change(:token, :crypto.strong_rand_bytes(32) |> Base.encode16!()or stuff.sodapopcan
There are definitely people who don’t think changeset functions belong in schemas!
I put changesets and queries in there, I don’t care
So long as they stay pure it doesn’t matter so much to me, it’s a nice obvious place for them. Though I also have a generic query module that has more generalized dynamic and “duck type” queries (like
for_useror whathaveyou). Also, anything that would be used by the “outside world” such as the predicates in your example aredefdelegated to from the context, so if I ever feel the need to slim down the schemas refactoring will be trivial (which is to not even mention that it’s keeping good boundaries).All that to say so long as you keep them pure, you won’t run into any trouble with fat schemas (like horrendous compile time dependencies).
katafrakt
I put them in separate modules. Depending on the size of the context and if it has “subcontexts”, either one or more. They are usually called
QueriesorQuerying, although perhaps I should just call them repositories.Defining the data and querying the data are separate concerns IMO. I don’t understand the remark about writing raw SQL.
dimitarvp
I dislike too much separate files. Especially in this case I don’t feel they provide any value. Having a schema + functions that manipulate its changesets is to me entirely valid.
sodapopcan
Queries are still static definitions on how we want to shape data, so it’s pretty related. For that reason I think you should stick with
QueriesbecauseRepositorymakes me think of the actual repository with side effects.I worked on a codebase where they insisted on putting queries in their own modules.
In fact, I do a thing that most would probably find cavalier: I put my
There were so many of them that just had one or two small queries in them which was insanely annoying therefore worked against DX. Separation of concerns is an important principle but like any programming principle, it doesn’t need to be followed dogmatically. Having queries in schemas is perfectly readable, workable, discoverable, and doesn’t cause any harm in compile times or any such things and in my experience a far better DX, so I always vouch for them to go there. I do keep a visual separation between queries and changesets, so they are still separated, just in the same module
import Ecto.Queryabove the first query as a kind of “header,” though that’s not something I would argue hard for in a shared codebase.katafrakt
I’m usually finding the opposite. The amount of queries grows almost infinitely in time, so I prefer to keep them in a separate module, where they don’t obscure other purposes of the unit of code. Even worse, the queries are usually more or less directly coming from UI requirements and to me it feels extremely weird to have UI dictate how the module closes to persistence looks like.
This can be partially addressed by keeping the query parts in schemas very generic and atomic. After all, composability is one of the main strengths of Ecto. But in that case you need some place when you stitch together the atomic query functions into something larger. I guess that would be a context. But having too many UI-driven query functions in context is a whole another discussion I’d like to have one day.
But yeah, I get your point.
sodapopcan
LOL ya sorry, I got a little emotional there and was channeling my frustration at past situations
My point wasn’t that I think separate query modules are bad, just that collocating them in schemas is fine if the situation allows for it.
Yes, the UI-driven query functions is a different discussion that I am interested in but I’ll keep this topic focused
eahanson
I put my schema modules in a top-level namespace called
Schema(for example,Schema.Profile). They contain just theschemadefinition and a@type.And then, I have a core module (for example,
Core.People.Profile*) that contains changeset functions as well as aQuerysubmodule that has composable query functions, which are assembled in context functions.I use Boundary to separate my
Coremodules from myWebmodules, but because both of them need to access schemas, I let both of them access theSchemamodules. I’m okay with that because theSchemamodules don’t contain any code.It might sound like a pain to have the schema and changeset functions in different files, but I wrote an editor plugin to jump between related files easily so it hasn’t been an issue for me.
*The Phoenix generators create top-level modules called
MyAppandMyAppWeb; I rename them toCoreandWebwhich has the advantages of being shorter and being easier to copy between projects.krasenyp
I have a separate top-level module
MyAppStorage. It exposes functions for querying and manipulating data which don’t return Ecto schemas. The schemas are only used internally. This way I keep full flexibility in the way I persist data. I can optimise as much as I want. At the same time my business entities don’t have to mirror my database tables’ structure.dimitarvp
I do like this approach but mostly found it good only after certain scale is reached. Most projects are just fine being tightly integrated with the “raw” Ecto schemas.