-
Notifications
You must be signed in to change notification settings - Fork 11
Add Support filters and search in count_ functions. #52
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
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
searchfunction, 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,
optsin Elixir always refer to options that modifies the behaviour of the function somehow. It's usually the last argument in the function (search_fieldswould modify that behaviour). The first arguments are generally the parameters that are uses to calculate something (this case the first argument would havefiltersandsearch, used to count the number of records of a schema)
| 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