If you have a class decorated with Queryable and then override the OData Queryable on a specific method in that class with ODataQueryOptions the Queryable Attribute will still throw a not supported error even if you have implemented that specific $filter.
This is a pretty common case where you'd want the default Queryable and then customize one or two methods in the class. Taking the Queryable attribute off the class and putting it on each method is highly non-optimal because of the maintenance issue that would be created.
The QueryableAttribute should recognize the docoration on the call and not throw if the method has a parameter of type ODataQueryOptions.
Comments: Hi Geminiman, I think you'll find that the new extension method HttpConfiguration.EnableQuerySupport() addresses your concerns. This method applies the [Queryable] attribute to all actions that return IQueryable<T> except those that take an ODataQueryOptions parameter. So you can implement your own custom filtering on actions that take in ODataQueryOptions, while having a single line that enables querying across your application.
This is a pretty common case where you'd want the default Queryable and then customize one or two methods in the class. Taking the Queryable attribute off the class and putting it on each method is highly non-optimal because of the maintenance issue that would be created.
The QueryableAttribute should recognize the docoration on the call and not throw if the method has a parameter of type ODataQueryOptions.
Comments: Hi Geminiman, I think you'll find that the new extension method HttpConfiguration.EnableQuerySupport() addresses your concerns. This method applies the [Queryable] attribute to all actions that return IQueryable<T> except those that take an ODataQueryOptions parameter. So you can implement your own custom filtering on actions that take in ODataQueryOptions, while having a single line that enables querying across your application.