Increase ResourceDefinition GetFilterQuery Flexibility

[joshhubers]

I really like the new ResourceDefinition interface, and it has allowed me to really separate and clean out some of the manual filtering I was doing traditionally in my EntityRepositories. That said, I do have a hitch with the following line:

JsonApiDotNetCore/src/JsonApiDotNetCore/Data/DefaultEntityRepository.cs

Line 98 in e58a48d

return defaultQueryFilter(entities, filterQuery.Value);

Is there are particular reason why the delegate takes only the filterQuery.Value and not the whole FilterQuery object (or at least value and operation)?

While the new ResourceDefintion has cleared up the basic filtering logic I have, I still have to keep messy logic for specific FilterQuery.Operation's.

public class FooRepository : DefaultEntityRepository<Foo>
...
public override IQueryable<Foo> Filter(IQueryable<Foo> foos, FilterQuery filterQuery)
{
  if(filterQuery.Operation == "in" && filterQuery.Attribute == "bar")
    return someInFilter(filterQuery.Value);
}
...

The new QueryFilter alias would then be something like:

public class QueryFilters : Dictionary<string, Func<IQueryable<T>, string, string, IQueryable<T>>> { }

or

public class QueryFilters : Dictionary<string, Func<IQueryable<T>, FilterQuery, IQueryable<T>>> { }

Such that in the ResourceDefinition GetQueryFilters you can also know the filter operation being used on the values provided.

I would be glad to get thoughts on this and eventually open a PR for this.

[maurei]

I'm not extremely familiar with the QueryFilter class but I don't see any clear objections. Would have to look into it. Meanwhile, a more elaborate proposal would be helpful in working through your idea! What are your recent thoughts on this?

[joshhubers]

@maurei I can look into implementing this this week, seems like the second idea would probably be best since it contains all the filtering information in a POCO and any future modifications to FilterQuery would make the custom filtering simpler in the future with access to the full object.

"second idea" being:
public class QueryFilters : Dictionary<string, Func<IQueryable<T>, FilterQuery, IQueryable<T>>> { }

[maurei]

Sounds good! I'm really curious if such implementations would break any tests that cover other parts of the framework. If not, we should be able to include it straight away.