wagtail-grapple
wagtail-grapple copied to clipboard
Filter pages with page model field
How can one use a page model field besides ID to filter pages? Decorating a page model with @register_query_field allows custom query parameters to be used with the singular query but not with the plural query.
Have you tried @register_paginated_query_field ?
Let me give it a try
@register_paginated_query_field only adds two more arguments(page and per page) to the plural query
The documentation says:
You can add custom query parameters like so:
@register_paginated_query_field(
"advert",
"adverts",
{
"id": graphene.Int(),
"url": graphene.String(),
},
)
then use it in your query:
{
# Get a specific advert
advert(url: "some-unique-url") {
url
text
}
}
so you should be able to replace url with you field in the definition
"advert" is the singular query in this case so that should work, my question is how do you get to specify such on the plural query "adverts", suppose we had a non unique field 'category' field on the model Advert and we want to query all adverts with that particular category
@register_paginated_query_field(
"advert",
"adverts",
{
"id": graphene.Int(),
"url": graphene.String(),
"category": graphene.Int()
},
)
adverts(category: 2){
url
}
The above wont work with the plural query which is supposed to return a list, adverts won't recognise category as an argument
advert(category: 2){
url
}
The above will recognize category as an argument but isnt for returning lists.
My question is how do we get plural queries to recognize custom query arguments
Ended up overriding @register_query_field to allow the plural query to be able to use custom query params just like the singular query
Hey @dilonne,
Can you share your overrides? I don't have lots of time this week, but keen to improve the developer experience, or documentation where possible
Sorry to do this twice in one day, but this is also still an issue in the latest version! I'm struggling to work out how to add filters to the plural query. @zerolab perhaps this should be reopened too?
@flyte @zerolab I think the underlying issue here may be that query_params isn't documented... looking at the code in register_singular_query_field it looks like the query params are passed to the filter function in the resolver. But in register_paginated_query_field ti doesn't seem to be, and this will likely break if search_query is set, since .search() handles filters differently...
dug a little more and...
- register_query_field.inner.Mixin.resolve_singular passes kwargs to get... (kwargs should be constrained to the arguments from the field definition)
- register_query_field.inner.Mixin.resolve_plural passes kwargs to resolve_queryset where they are not used.
register_paginated_query_field suffers from the same limitation where kwargs is passed to get in resolve_singular, and to resolve_paginated_queryset in resolve_plural, but then resolve_paginated_queryset never passes **kwargs to filter.
There are a few routes a fix could probably go.
- register_query_field.inner.Mixin.resolve_plural could pass
qs.filter(**kwargs)to resolve_queryset instead ofqs.all() - resolve_queryset could be modified to call qs.filter(**kwargs).
It may be better to apply kwargs in resolve_queryset so that any special conditions around search filters can be properly handled.
It looks like the same change in both resolve_queryset and resolve_paginated_queryset would address this...
- qs = qs.all()
+ qs = qs.filter(**kwargs)
At the same time we fix this we should probably document that the syntax for these argument name should use django field lookup syntax ex) field: value for exact match, field__gt: value for a greater than match.