You can pass the prefix as part of the query_opts:
Flop.validate_and_run(query, params, query_opts: [prefix: "some_prefix"])
woylie
2
victorbjorklund
Majd
A bit of a late reply, but, to improve your life even more, you could store the prefix in the process once you determine the tenant, and use the prefix in the repo’s default option. This would abstract providing the schema prefix from almost all of your app (I say almost cuz sometimes you’d need to explicitly set the prefix, eg: tests).
Here’s how we do it in our app:
defmodule MyApp.Repo do
use Ecto.Repo,
otp_app: :my_app,
adapter: Ecto.Adapters.Postgres
.
.
.
@impl true
def default_options(_) do
[prefix: get_tenant()]
end
@doc """
Hold :prefix in option in the current process space
"""
def set_tenant(tenant) do
Process.put({__MODULE__, :prefix}, tenant)
tenant
end
def get_tenant do
Process.get({__MODULE__, :prefix}) || "public"
end
end
The only piece left in the puzzle is setting the prefix once you determine the current tenant, eg: access to domain <tenant-subdomain>.example.com → prefix = <tenant-subdomain>
MyApp.Repo.set_tenant("<tenant-subdomain>")
Hope this helps!
1
linusdm
Is there a convenient way to have an final order applied after all requested orders have been applied? The goal is to have a stable list, even when sorting by a condition that has many large buckets of the same value. Adding a sort order by id (or inserted_at for example) as the last order by clause can make the final list stable.
The default order doesn’t help here, because I want to add the order clause in any case. Ecto only allows Ecto.Query.prepend_order_by/3. I don’t think there is any way to intercept the final query, and append a sort order after Flop has augmented the passed-in query. Unless I’m missing something here… 
Oh, I’ve asked about this before 
(A different way of manipulating ordering fields and directions, and combining with the configured default ordering. · woylie/flop · Discussion #349 · GitHub) I didn’t remember. Sorry for the noise.
1
sodapopcan
Seems this is the place to ask Flop questions. Not sure if it’s ideal over starting a new thread but here I am!
Is there a less verbose way to, on the fly, build a path with filters than this:
build_path(~p"/admin/catalog",
%Flop{
filters: [
%Flop.Filter{
field: :collection_id,
value: collection.id
}
]
}
)
I may be having a brain blip as I feel as if I’ve done this before but I can’t remember or find it 
0
woylie
I don’t think there’s a less verbose way to do that short of writing out the query parameters directly.
1
sodapopcan
Thanks, @woylie! I realized that I have never actually used it (obviously), I just thought about it. I have an app for a client that is (if you can believe this) a glorified spreadsheet. There are several pages where I link to the main table view with pre-filled filters. I remembered that I ended using dropdowns out of laziness the convenience of Flop.Phoenix.filter_fields/1 even though links would be better. This is the first app I ever used Flop with and I don’t work on it very often so there are some odd decisions lurking that I made while learning.
It’s not like status quo is bad but a shorthand might be nice. Would you be open to that? Something like:
build_path(path, filters: [field: value])
build_path(path, filters: [field: {:>=, value}])
build_path(path, page: 2)
Thinking out loud here and not sure if it’s a problem many people face or what can of worms this might open. I’m happy to do the work if you’re open to it, though.
0
woylie
I’m not sure I’d want to officially support this at the moment. I thought I opened an issue before about a simplified filter syntax, but I can’t find it. I feel like there are more pressing issues right now, and this would just add unnecessary complexity. If you find it useful, you can add a wrapper around build_path to your application (and maybe share it). Might think about this again in the future.
1
itzmidinesh
Is there a way to return errors in the same format as Ecto changeset errors?
I’m making a request like this:
/api/posts?filters[0][field]=invalid_field&filters[0][value]=value
It returns meta struct with errors like this:
%Flop.Meta{
backend: nil,
current_offset: nil,
current_page: nil,
end_cursor: nil,
next_offset: nil,
next_page: nil,
page_size: nil,
previous_offset: nil,
previous_page: nil,
schema: MyApp.Posts.Post,
start_cursor: nil,
total_count: nil,
total_pages: nil,
errors: [
filters: [
[field: [{"is invalid", [validation: :inclusion, enum: [:is_public]]}]]
]
],
flop: %Flop{
after: nil,
before: nil,
first: nil,
last: nil,
limit: nil,
offset: nil,
order_by: nil,
order_directions: nil,
page: nil,
page_size: nil,
decoded_cursor: nil,
filters: []
},
has_next_page?: false,
has_previous_page?: false,
opts: [for: MyApp.Posts.Post],
params: %{"filters" => [%{"field" => "invalid_field", "value" => "value"}]}
}
What is the best way to convert meta.errors into a human-readable format before returning a JSON response in Phoenix?
0
woylie
meta.errors contains the errors in the same format as Ecto.Changset. You should be able to transform them with Phoenix’s translate_error function:
Except in your case, you probably want to transform the errors of all fields recursively, instead of only a single field.
1