-
Notifications
You must be signed in to change notification settings - Fork 11
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add Support filters and search in count_ functions. #52
base: master
Are you sure you want to change the base?
Conversation
def unquote(:"count_#{pluralized_name}")(opts \\ [], repo_opts \\ []) do | ||
field = opts[:field] || :id | ||
search = opts[:search] | ||
search_fields = opts[:search_fields] || [] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would that be a good one? Leave search_fields as default with all module fields?
search_fields = unquote(module).schema(:fields)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Don't know... First, we would need to take care of excluding fields that are embededd schemas (which are returned by __schema__(:fields)
.
Also, a search in all fields would include, timestamps, id's, etc. and I don't see this being useful. Most of the cases we define which fields should be searchable.
But I also feel that having to define the search fields every time we use the function is not so good. I suggest that we add the search_fields
as an option of the generate_function
, and do something like opts[:search_fields] || unquote(generate_opts)[:search_fields]
.
Also, should we raise an error if the user dont define this option anywhere and the search
parameter is sent?
One more thing here, I think the :search_fields
option should come from the second parameter (renaming repo_opts
to opts
and opts
to count_params
or something`)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Yes, maybe the generation of this new function is a good idea, we could use it in the
search
function, today it uses the same logic.
module_fields = unquote(module).__schema__(:fields)
-
I don't think we need to return an error here, as the search_term attribute in the search function can be nill or an empty string.
-
Hmm, I don't know, it looks so good this way, I wouldn't understand why all the attributes specified as opt, and this one doesn't.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Nice! I think changing the
search_
it would be nice too. (Just remember to not do a breaking change, there I think we need to default to all fields in the schema) -
My idea is when the search_term is not null (nor empty) AND the search fields are not defined
-
It's because generally speaking,
opts
in Elixir always refer to options that modifies the behaviour of the function somehow. It's usually the last argument in the function (search_fields
would modify that behaviour). The first arguments are generally the parameters that are uses to calculate something (this case the first argument would havefilters
andsearch
, used to count the number of records of a schema)
@@ -105,8 +105,15 @@ defmodule ContextFunctionsGenerator do | |||
|
|||
def generate_function(:count, _name, pluralized_name, module, opts) do | |||
quote do | |||
def unquote(:"count_#{pluralized_name}")(field \\ :id, repo_opts \\ []) do | |||
def unquote(:"count_#{pluralized_name}")(opts \\ [], repo_opts \\ []) do |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
2 things here:
- What do you think about adding typespecs?
- This is a breaking change, since the first parameter is changing. So there's two options here, accept the breaking change and start planning the next major version (since there are plans to also change the
list_
functions as well) or we can add a guardwhen is_atom(field)
andwhen is_map(count_params) or when is_list(count_params)
, keeping the compatibility
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @gabrielpra1
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can create a more specific problem for using typespecs since it's something we're not using yet, taking advantage of the idea of doing this for filters and other functions.
About the rupture change, we can make this adjustment using guard 👍
Until we created a new version removing all deprecated functions.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
-
Okay, probably we could add typespecs later.
-
Agreed!
This PR intends to add filter and search support for count functions.
Related by #49