Closed alanpeabody closed 8 years ago
@beerlington @Dangeranger currently the index action has some not very well documented hooks for sorting and filtering based on the sort
and filter
query params.
The function signature for them is:
@callback filter(String.t, JaResource.records, String.t) :: JaResource.records
@callback sort(String.t, JaResource.records, String.t) :: JaResource.records
Where the first string is the key and the second the value. For example to filter based on type:
When executing: GET /v1/articles?filter[status]=draft
def filter("status", query, status), do: where(query, status: status)
This all works, but it feels weird and inconsistent to me for the following reasons:
Sort is the same way, and I could foresee handling include
in a similar fashion where we add preload
statements on as needed.
What do you guys think?
@alanpeabody I'll try to look at this later tonight. Thanks for the heads up.
it seems like it should be:
def filter(query, key, value), do: ...
@beerlington you don't think conn needs to be in there?
I have been thinking about filters where allowing the filter would be dependent on the user.
Oh I missed that part. we'll be doing some filtering on a project soon and might have more feedback later this week.
@alanpeabody If conn
is passed in everything else I would expect it to be first like:
def filter(conn, query, [key: value]), do: where(query, key: value)
This query could get passed on to the next call to filter
if there were query params like:
GET /v1/articles?filter[status]=published&filter[author]=12
Yup, each key/value pair is passed to filter and with the query the last returned.
I think filter(conn, query, key, value)
might be the way to go. Matching keyword lists is discouraged and a pain, it would have to be filter(conn, query, [{key, value}])
but we can just pass them positionally.
Should they include the conn? What argument order really makes sense?