What do you have in your Schema apart from changeset functions?

Questions / Help
,
1

I’m not sure what is good to keep in the Schema’s apart from changeset. Usually my Schema will have a def changeset/2function and possibly other functions creating/modifying changesets.

What else is good to keep in a Schema? Do you put helpers to build queries? Can I see some examples of some of your Schema?

Thank you!

2 Likes
2

I would put all functions related to the underlying module structure, but not the queries. I would also delegate all methods to the context.

One good thing to learn how it is organized is to use the generators (mix phx.gen.context etc.) and look at the generated files.

Usually, You end up with schema and changeset only, then queries are inside contexts.

I prefer to have dedicated functions queries, that I pipe into a Repo.all()

One good thing is You can organize the files as You want, with whatever names You want… Elixir will find your modules by atom.

You could decide to separate all queries into their own modules.

3

From the “Programming Ecto” book:

As a general rule, we recommend putting the pure functions that manipulate
queries, changesets, and multis into their associated schema modules.

Also:

Changesets, queries, and multis are pure data structures that
describe impure actions against the database, but these actions don’t take
place until we run them through the functions provided by Repo. This creates
a clear distinction between code that has side effects and code that doesn’t.

It seems that it is advised for the query builders to be in the Schema itself.

Example from the book:

defmodule MusicDB.Music.Album do
  use Ecto.Schema
  import Ecto.Query
  alias MusicDB.Music.{Album, Artist}

  schema "albums" do
    field :title, :string
    belongs_to :artist, Artist
  end

  def search(string) do
    from album in Album,
      where: ilike(album.title, ^"%#{string}%")
  end
end
3 Likes
4

But the generator I was mentionning does not… it puts queries inside context.

Anyway I do agree queries could be put in schema, but I don’t like to have to import Ecto.Query in it. I prefer to have a separate queries folder, with dedicated modules.

UPDATE:

defmodule MusicDB.Music.Album do
  ...
  import Ecto.Query
end

I don’t see why the schema should know about Ecto. But it is just a personal preference.

Phoenix is flexible enough to easily support how You want to organize your project.

5

I have both changeset, build, and query functions within the schema module.
I am, however, trying to move the query functions out into separate modules. When having fairly complex changeset logic as well as functions that operate on the schema-struct itself, I find that the schema modules can grow quite big. Thus I think it makes sense to move the query functions out.
Besides a few simple queries (e.x. fetch all elements belonging to a specific user), more complex queries tend to be more specialized and may even perform joins with other schemas. In those cases it makes more sense to have more specific (and smaller) query modules.

1 Like
6

The file generated by mix phx.gen.context only really do calls to Repo, which is impure, and which consequently should be placed into the context; the code generated doesn’t build queries with the query DSL and so on, which the author advises to put into the Schema.

7

Here is some contexts code I wrote, for a graphql backend…

  def list_player_games_query(%Player{id: player_id}, args) do
    from(
      g in list_games_query(args),
      where: g.white_id == ^player_id or g.black_id == ^player_id
    )
  end

  def list_player_games(%Player{} = player, args \\ []) do
    player
    |> list_player_games_query(args)
    |> Repo.all
  end

That is how it is organized in Crafting GraphQL. Again, I don’t pretend it is the best way… but It makes also sense to have queries inside contexts.

When You use the generator, it puts an alias to Repo, and imports Ecto.Query in the context.