1

Closed

OData: Unknown $xxxx throws not supported with Queryable()

description

Currently it doesn't support basics like $format and $inlinecount that all clients will pass. Most of the time we have no control over it. Unknown commands should not throw.
Closed Oct 18, 2012 at 11:57 PM by hongyes
Close the issue as ValidateQuery is virtual now. Anyone want to extend QueryableAttribute can override this method to accept it's own query.

comments

HongmeiG wrote Aug 17, 2012 at 11:21 PM

Make the ValidateQuery extensible so that one can override this behavior.

roncain wrote Aug 21, 2012 at 5:17 PM

Issue addressed with http://aspnetwebstack.codeplex.com/SourceControl/changeset/dc86e1cb7766

The default behavior did not change, but QueryableAttribute.ValidateQuery was made virtual to allow new query parameters or a different kind of response for unsupported ones.

interscape wrote Aug 22, 2012 at 3:57 AM

How would one go about overriding the default behavior so that $skip and $top do not throw a 406 anymore?

Thanks!

roncain wrote Aug 22, 2012 at 2:11 PM

I recommend subclassing QueryableAttribute, overriding ValidateQuery, letting the base.ValidateQuery() do its thing inside a try/catch that you can post-process. If you look at the base ValidateQuery in http://aspnetwebstack.codeplex.com/SourceControl/changeset/dc86e1cb7766#file_diff_src/System.Web.Http.OData/QueryableAttribute.cs you can see how it was making its decisions.

Now that we publish nightly-builds of the Extensions packages (http://aspnetwebstack.codeplex.com/discussions/392518) you should have access to this recent change.

Under what circumstances were $skip and $top throwing 406? There was a recent bug fix (http://aspnetwebstack.codeplex.com/SourceControl/changeset/b11acf178a83) to permit $skip and $top to work over collections of primitive types. Was that related to your scenario?