Ah, so the thought is allow clients create an extension module that are passed in to QueryBuilder like so?
use QueryBuilder, extension: MyApp.QueryBuilder.SearchFunction
MyApp.QueryBuilder
defmacro __using__(opts) do
extension = Keyword.get(opts, :extension, QueryBuilder.NullExtension)
# confirm its a module with __using__
quote do
require QueryBuilder.Schema
QueryBuilder.Schema.__using__(unquote(opts))
require unquote(extension)
unquote(extension).__using__(unquote(opts))
end
end
The clients can use just query builder as currently documented. No defdelegates required and no from_list overrides needed. Its worth a shot, though injecting macros can be complex if the extension macros have other macro operations such as setting module attributes which my extension module does. It’s worth a try to see how that plays out in my case.
That’s one approach, or introducing :self as a sentinel for the current schema to resolve to a field. So:
User
|> QueryBuilder.where([auth_method: :email@self, auth_val: "someone@example.com"])
|> Repo.one!()
Resolves to the current functionality as today, and:
User
|> QueryBuilder.where([auth_method: :email, auth_val: "someone@example.com"])
|> Repo.one!()
works like Ecto does today, while modeling the current association syntax you have.
Thoughts? Either way, it’s worth creating issues, and I can take a stab at working on the functionality suggested in a new branch or just fork the repo and PR back in after implementing. Definitely need to address the atom field referencing to use this lib
But what I will do I think is make a stable version 1.x and it won’t bother anyone. Having e.g.