Limit OpenAPI filter operators based on attribute/argument type

[nallwhy]

Is your feature request related to a problem? Please describe.

In AshJsonApi.OpenApi.raw_filter_type/2, all of Ash.Filter.builtin_operators/0 are included when generating filter schemas, regardless of the attribute or argument type. This results in many irrelevant or inapplicable filters being included in the schema.

e.g. Filtering operators like contains, length, or ilike appear even for types where they don’t make sense (e.g., integer), which can be confusing or misleading in the generated API documentation.

Describe the solution you'd like

It would be great if the available filters could be limited based on the type of each attribute or argument. That way, only relevant operators would be included in the filter schema.

Describe alternatives you've considered

no

Express the feature either with a change to resource syntax, or with a change to the resource interface

I have no idea.

Additional context

For now, I’m proposing this change here, but it might actually require modifications in the ash library itself, depending on the desired approach.

[zachdaniel]

Okay, so this one is actually a bit complex. I think what we need to do is to allow types to have a callback that says "what kind of type do I filter like", i.e def filters_like(_constraints), do: [:string]". Alternatively we may want to make a json_api specific callback for types that says "what predicates do you support", and then we implement that question for all builtin types?

[zachdaniel]

Not the simplest thing of all time, but doable. I like the idea of doing it at the API level and not in core though.

[nallwhy]

Not the simplest thing of all time, but doable. I like the idea of doing it at the API level and not in core though.

I agree with your take — since this hasn’t been a requirement in ash itself so far, I also think it’s better to keep this outside of core for now. If a need arises in core in the future, it can be reconsidered then.

Would you prefer handling this kind of logic via a protocol?

[zachdaniel]

Not a protocol in this case because we will be dealing with type modules. I think it will be a big case statement effectively of builtin types, with the fallback checking for a function on the type.

[nallwhy]

common_operators = [
  Ash.Query.Operator.IsNil,
  Ash.Query.Operator.Eq,
  Ash.Query.Operator.NotEq,
  Ash.Query.Operator.In
]

# number, date, time
comparable_operators = [
  Ash.Query.Operator.LessThan,
  Ash.Query.Operator.GreaterThan,
  Ash.Query.Operator.LessThanOrEqual,
  Ash.Query.Operator.GreaterThanOrEqual
]

comparable_types = [
  Ash.Type.Integer,
  Ash.Type.Float,
  Ash.Type.Decimal,
  Ash.Type.Date,
  Ash.Type.UtcDatetime,
  Ash.Type.NaiveDatetime,
  Ash.Type.Time
]

# string
string_operators = [
  Ash.Query.Function.Contains,
  AshPostgres.Functions.Like,
  AshPostgres.Functions.ILike,
  AshSqlite.Functions.Like,
  AshSqlite.Functions.ILike,
  AshMysql.Functions.Like,
  AshMysql.Functions.ILike
]

string_types = [
  Ash.Type.String,
  Ash.Type.CiString
]

I’m not quite sure when exactly I’m supposed to apply these.

[zachdaniel]

Hm...could you take a look at what we do for this in ash_graphql? I think we have some logic we apply to ensure that filters are handled in a sort of logical way, although I think we are going to need to find ways for custom types to express predicate filters that make sense for them (that filters_like callback I mentioned maybe?). I'm not sure yet what this all looks like TBH.