I’d say we missed the obvious solution here - anonymous functions.

If we were talking about a single function instead of whole repo - this would be obvious with using partial application, wouldn’t it?

prefixed_insert = &Repo.insert(&1, prefix: "foo")
prefixed_insert.(my_data)

So can we do something similar for a module? We need to do some changes, mainly because now we need to decide at runtime which function to call, fortunately we can use apply/3.

def prefixify(prefix) do
  fn fun, args ->
    [opts | rest] = Enum.reverse(args)
    apply(Repo, fun, Enum.reverse(rest, [Keyword.put_new(opts, :prefix, prefix)])
  end
end

This allows us to call:

prefixed = Repo.prefixify("foo")
prefixed.(:insert, [my_data, []])
prefixed.(:all, [some_query, []])

It’s a bit different than the original, but achieves the goal. Is it worth it and should be done? That’s a completely different question

Nov 2, 2016 Update

So indeed my tests were where I was feeling the most pain.

I worked out a solution in 2 parts for that.

1. I’m running a test_seeds.exs script at the beginning of all of my specs to do standard setup. That’s reduced general duplication quite a bit, and sped the specs up tremendously as well (9 sec -> .8, because the specs were actually creating tenants)
2. Where I am creating extra setup data, I was unable to use the Ecto strategy for ex_machina, because I couldn’t set the prefix on those structs. So I created a PR for ex_machina (ExMachine PR) that kinda feels like ‘traits’ from factory girl.

When I get back to this project, I’ll look into @josevalim’s insight about Ecto 2.1, and its ability to accept the prefix as a keyword to Repo operations. That is probably the ‘good enough’ solution right there!

Oct 31, 2016 Update

Update for future readers. I realized that the place I was noticing all of this painful duplication was in my specs. But my specs are usually only using a single prefix, and part of the struggle was with ex_machina needing a new (prefix) parameter that hosed its lovely strategy pattern. So the compromise solution I’m going with now is to create a test-only import file that will wrap ex_machina, letting me pass in a tenant that is defaulted to a ‘test’ tenant. And then also wrappers around the Repo that do the same. So far (this is a work in process), I’m not planning to use the wrappers in my production code, because my methods are short, and so I’m comfortable seeing the specification of the tenant. Hopefully, once this is is all complete, I’ll bake it in to the library docs.

That said, if there’s a solution to my original question that I’ve missed, I’d still really like to know!

You could use the pipe operqator |> and instead of:

do

repo = Repo.prefixify(123)
%User{}
|> User.changeset(%{name: "joe"})
|> repo.insert

Also if the module where you to this is User specific you might consider import User
EDIT: Expanded original answer
Regarding the prefix: How about using something like this:

defmodule User do
  defmacro __using__(prefix) do
    quote do
      use Ecto.Schema
      @schema_prefix prefix || Application.get_env(:ex_machina, :prefix, "public")
      #... all the other user stuff
  end
  end
end

and then

defmodule MyPrefixUser do
  use User :my_prefix
end

Thank you for the detailed writeup, @pba. I wasn’t as clear as I should have been on what I was trying to achieve. The problem I’m struggling with was how to write the function Repo.prefixify(123), such that it returned a version of the Repo that would apply the given prefix to either the query or changeset appropriately. The problem is that the prefix will change based on each request. I’m using postgresql’s schemas to isolate client data. As a result, I can’t set the prefix in a config. Poor explanation on my part. Thank you for the input!

Each request gets its own process. The Erlang scheduler ensures nothing shared between processes. There is no pool of processes (rather a pool of memory, it is low level stuff, just assume erlang does things right, because it does ^.^), no need to clear it unless you want it cleared for your current request for some reason.