Ash resource filtering embedded map with user input

Ash Forum Ash Questions / Help
,
1

I am trying to parse a user generated filter that will apply to jsonb field (that is just a map, not an embedded resource).

The field is data, and if I include it in the statement sent to parse_input I get an Ash.Error.Query.NoSuchFilterPredicate error.

If I exclude that field, and instead manually apply it, |> Ash.Query.filter(data[:size] == ^"Big") then things works.

Is there a syntax to allow passing fields of a map into the parse function? If not, how can I pass it to Ash.Query.filter? To make it slightly more complicated, I would also like to be able to filter on the data field when it is on a reference as well. e.g. `%{person: %{data: %{size: “Big”}}}

    statement = %{
      person: %{parent: %{name: "Daniels"}},
      data: %{size: "Big"}
    }

    # This will blow up with the above
    {:ok, filter} = Ash.Filter.parse_input(resource, statement)

    # If I remove "data" and instead do it manually, then this works:
    resource
    |> Ash.Query.for_read(read_action, %{}, actor: actor, tenant: tenant)
    |> Ash.Query.filter_input(filter)
    |> Ash.Query.filter(data[:size] == ^"King")

https://elixirforum.com/t/filtering-on-embedded-resource/59085/6 was where I saw the Ash.Query.filter approach on arbitrary fields of a jsonb attribute; I just couldn’t figure out how to pass my user generated filter since that is a macro.

Thank you!

2

I think this is actually something missing from Ash.Filter, specifically when given a nested map like that we should check for embedded resources and allow you to apply that kind of filter. Could you open an issue for it in Ash?

Another way to achieve this kind of thing is to add calculations to the root resource, i.e


```elixir
calculate :size, :string, expr(data[:size])

and then allow filtering on :size. Not a feasible option for every case though.

3

Created Filter a map attribute using user input · Issue #862 · ash-project/ash · GitHub

The size filter was just an example, it could be any field, and deeply nested. Basically, that data field maps to a JSON schema that is defined at runtime. I hacked together an approach using fragments that works fine until you join another table that also has a data field, and postgres has the ambiguous error. I saw in another post using an as(0) notation, but that seems hokey for my case and also wasn’t sure how to in the fragment.

There is no “hidden” method I can call that replicates what Ash.Query.filter(data[:size] == ^"King") is doing? Because I am fine breaking out the data filters into another approach while keeping parse_input for the pre-defined attributes.

4

There are definitely ways to build the filter yourself and to dynamically build references that won’t bring on the ambiguous references that you mentioned, i.e a simplified thing

require Ash.Expr

...
map
|> Enum.reduce(true, fn {key, value}, expr -> 
  Ash.Expr.expr(ref(^key) == ^value) and ^expr)
end)

This can be adapted to support nested keys and to do things like get_path(ref(^key), ^list_of_keys) == ^value).

However, I’ve just pushed support for doing this automatically with non-array embedded types in input filters to ash main. Keep in mind there is still some experimental stuff in main, and if you want to use it you should also upgrade ash_postgres to latest main as well.

5

You’re a machine! :joy: What cup of coffee are you on?

I pulled main for ash and ash_postgres and it had the same error.

I think your new code worked because the attribute is defined as attribute :embedded_bio, EmbeddedBio and not attribute :embedded_bio, :map

I hacked up my own embedded resource and attached it to my data field and the code works. But I need it for a generic :map

Sorry for the bad news :frowning:

I don’t want to abuse you, so I’ll reopen the github issue and get to it when you can. Thanks!

6

Ah :thinking: so, this is a bit harder. The reason for that is that you can use a predicate %{data: %{eq: 10}}, and we can’t tell if you mean data.eq == 10 or data == 10. The format is, unfortunately, a bit ambiguous. We’d have to figure something else out to for this. :thinking:

EDIT: to make it clear, you can use all kinds of predicates, like %{data: %{less_than: 10}}

7

I’m thinking what we need to do actually is walk back the previous change, and introduce a new syntax for including paths in input. Perhaps something like this:

%{data: %{at_path: ["foo"], eq: 10}}
8

So, I made that change and realized that it just kind of shuffles the problem around, because if you have an attribute called at_path it would be problematic…but actually I think it’s fine. The reason its fine is that at_path expects a list, and if you need to match on it you can say at_path: %{eq: ["foo"]}, so there is an escape hatch (albeit a bit of a convoluted one)

9

Alright, I’ve pushed this change to main (and removed the previous change I added)

1 Like
10

(edit: replied before seeing your new change. let me do that first)

Can you see in the filter logic that data is an Ash.Type.Map so any condition being applied to it would actually be for fields in the map?

For your example, I wasn’t sure how to use it.

    resource
    |> Ash.Query.for_read(read_action, %{}, actor: actor, tenant: tenant)
    |> Ash.Query.filter_input(filter)
    |> Ash.Query.filter(
      Enum.reduce(%{size: "King"}, true, fn {key, value}, expr ->
        Ash.Expr.expr(get_path(ref(:data), ^key) == ^value and ^expr)
      end)
    )

Do you have a more complete example of using Ash.Expr.expr because elixir ain’t happy with that. Can’t find key, value, expr.

11

Can you see in the filter logic that data is an Ash.Type.Map so any condition being applied to it would actually be for fields in the map?

This covers the case a little bit, but there can also be custom types that are backed by maps, and we can’t detect them all.

Do you have a more complete example of using Ash.Expr.expr because elixir ain’t happy with that. Can’t find key, value, expr.

You need to require Ash.Expr because Ash.Expr.expr is a macro.