How to create macro to implement get function of Ecto?

How would your macro look at the call-site? What does it have over Repo.get_by(Schema, pk1: pk1, pk2: pk2)?

Yes, it’s because __CALLER__ is not yet compiled. You can create a MyApp.Queries module and pass MyApp.MySchema as second argument instead.

I’m writing it from memory, so I could make a mistake, but it should work:

defmodule Example do
  defmacro defquery(type, module_ast) do
    module = Macro.expand(module_ast, __ENV__)
    primary_keys = module.__schema__(:primary_key)
    module_snake_case = module |> Module.split() |> List.last() |> Macro.underscore()
    call_args = Enum.map(primary_keys, &Macro.var(&1, module))
    func_name = :"#{type}_#{module_snake_case}"
    repo_args = Enum.map(call_args, &{elem(&1, 0), &1})
    repo_func = get_repo_func(type)

    quote do
      def unquote(func_name)(unquote_splicing(call_args)) do
        apply(MyApp.Repo, unquote(repo_func), [unquote(module), unquote(repo_args)])
      end
    end
  end

  defp get_repo_func(:get), do: :get_by
end

defmodule MyApp.Queries do
  require Example

  Example.defquery(:get, MyApp.MySchema)
end

MyApp.Queries.get_my_schema(…)

This is fully generic macro. Feel free to edit it as you wish.

It’s also possible to change this code to work inside MyApp.MySchema, but that’s not recommend as such modules are designed to handle different things (field definitions, changesets etc.) and business logic should be inside context modules. That was already well described on forum.

For me it looks like that author want to have instead: Schema.get(pk1, pk2). For me it does not looks that bad, because in Repo.get_by/2 you don’t know which keys are primary (h helper in iex and on documentation level). Here you could see them in generated documentation.

The only problem is that author probably want to generate such functions inside modules with schema definition. Instead I proposed example with same functions, but in context module.

In order words instead of:

MyApp.Repo.get_by(MyApp.Comment, [id: comment_id])
MyApp.Repo.get_by(MyApp.PostComment, [comment_id: comment_id, post_id: post_id])
MyApp.Repo.get_by(MyApp.Post, [id: post_id])

author wants:

MyApp.Comment.get(comment_id)
MyApp.Post.get(post_id)
MyApp.PostComment.get(comment_id, post_id)

and my macro allows to call like:

MyApp.Queries.get_comment(comment_id)
MyApp.Queries.get_post(post_id)
MyApp.Queries.get_post_comment(comment_id, post_id)

Allows for an easy typo, get_by is better at least in that regard. Also, I’d make it get_post_comment(post_id, comment_id)?

Not sure if I remember it correctly, but when using such generator then thing which matter is order of field definition (assuming that there is no sorting in generator etc.), so for example:

defmodule MyApp.PostComment do
  use Ecto.Schema

  @primary_key false
  schema "posts_comments" do
    belongs_to :comment, MyApp.Comment, primary_key: true
    belongs_to :post, MyApp.Post, primary_key: true
  end

  # …
end

would give: MyApp.PostComment.__schema__(:primary_key) == [:comment_id, :post_id]

and simply changing fields (here belongs_to calls) order like:

defmodule MyApp.PostComment do
  use Ecto.Schema

  @primary_key false
  schema "posts_comments" do
    belongs_to :post, MyApp.Post, primary_key: true
    belongs_to :comment, MyApp.Comment, primary_key: true
  end

  # …
end

would give: MyApp.PostComment.__schema__(:primary_key) == [:post_id, :comment_id].

Again I wrote it from memory and it could not even compile due to typo or other small mistake.

Also I’m not sure if get_by is better in this case. In modern (of course well supported by Elixir extension/plugin) editor and in app with no similar model names (like MyApp.Worlds and MyApp.Words) there should not be any problem as editor should give proper hints and auto completion. Same goes to arguments order as they would be corrected by editor app.

Finally I’m not sure if post_id (always) should be before comment_id. For lots of cases order really matters, for example it’s easier to write pipe calls. However in cases like here (many-to-many assoc model) we can go from comment_id as well as from post_id - everything depends on scenario and I don’t think that force change of order is best idea (again in this particular case).

Keep in mind that Comment and Post are just most popular in database examples, so even if you would always go from Post and never from Comment then everything change in real world app where both of sides are important unlike Comment which is nice to have enhancement to Post.

Of course it’s only how I think and it’s definitely not an rule from senior developer.