Trying to better understand filter in the context of AshGraph
I am trying to work through some basics of AshGraph, and in the guide it has you set up a filter with code like:
https://ash-hq.org/docs/guides/ash_graphql/latest/graphql-generation#filter-data-with-arguments
I'm having trouble understanding what is going on here. I am particularly confused about the
is_nil
check and why this is an or
.
When I run a query like:
It works as expected (I only get back tickets with that representativeId
. But then, when I try:
I get back all tickets, those with a null
representativeId
and those with a proper id.
My code is here in case that helps provide context: https://github.com/zorn/helpdesk-elixir-api11 Replies
To try to add clarity: How would I go about building a filter so that, if the incoming graph query was explicitly asking for
{"representativeId": null}
I would be able to return a list of tickets where that was true.
I feel like I am missing the concept of "did they include representativeId
in the graph query at all, and then if they did what was its value, .. null
being a valid value.The
is_nil(^arg(:representative_id))
is talking about the argument being nil
A clearer statement would be:
So if they provide a representative_id
we return only those and if they do not, we return everythingprepare
goes in exp
or filter
?
nevermind I think I see.. it's a DSL on read
. https://ash-hq.org/docs/dsl/ash-resource#actions-read-prepareYep!
The way that ash expressions work, they are eagerly evaluated when possible
So in the case of
is_nil(^arg(:representative_id)) or representative_id == ^arg(:representative_id)
if the argument :representative_id
is nil
, then the whole statement is true and no filter is applied
This would be the same behavior if they weren't eagerly evaluted, but its an optimization that they areIs it a fair assumption that the expressions in
exp
have the be guard-like?
I tried just using a simple
and I'm seeing representative_id
show up as a nil
argument evenwhen the graphql query does not include it.
it would need to be something like the following to provide a value
Expressions do not need to be guard-like
They are their own thing
My current observation is that both:
and
Both debug like:
I would have expected that when the argument was not present in the graph query it would not be present in the
Ash.Query
and would debug more like:
I guess what I'm missing is that there is no way to define representative_id
as an optional argument in the read action.That looks like a bug 🙂
Trying to figure out why that would be the case
the way we currently handle it is like so:
So if the key isn't present it shouldn't be set as an argument
Can you open an issue on
ash_graphql
about this please? I'll investigate tonight or tomorrowGitHub
When a graph query has no arguments, I expect the
Ash.Query
objec...I'm new to AshGraph, and while tinkering, I discovered an unexpected behavior where even when I do not define any arguments in the graph query the Ash.Query always contains the field name in th...
To close this thread, @Zach Daniel saw the error source of the confusion which was an incorrect Inspect prootocol in the main ash project. The ticket was updated and has the needed links.
In my own project I have the behavior I am looking for with: