Add Support filters and search in count_ functions.#52
Add Support filters and search in count_ functions.#52rafaelofreitas wants to merge 2 commits intojungsoft:masterfrom
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.
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.
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.
- 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.
-
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.
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.
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.
-
Okay, probably we could add typespecs later.
-
Agreed!
2 participants
This PR intends to add filter and search support for count functions.
Related by #49