Where did QueryableAttribute.ApplyResultLimit go?

Topics: ASP.NET Web API
Aug 21, 2012 at 2:21 PM

I have used QueryableAttribute.ApplyResultLimit to add metadata to the results returned by a query as described here http://www.strathweb.com/2012/06/extending-your-asp-net-web-api-responses-with-useful-metadata/#comment-4606

Basically, the idea is to grab the IQueryable state before any OData operators are applied to it, and transform the response to have information based on that, too.

However, after MVC4 RC that the OData support was removed and put in a package, ApplyResultLimit seems to have been removed.

How may I replicate this behavior with the new model?

Thanks

Aug 21, 2012 at 4:58 PM
Edited Aug 21, 2012 at 4:59 PM

You don't need the ApplyResultLimit method. You can override the OnActionExecuted method and do something like,

  

    public class CustomQueryableAttribute : QueryableAttribute
    {       
        public override void OnActionExecuted(HttpActionExecutedContext actionExecutedContext)
        {
            base.OnActionExecuted(actionExecutedContext);
            
            object responseObject;
            actionExecutedContext.Response.TryGetContentValue(out responseObject);
            var originalquery = responseObject as IQueryable<object>;

            if (originalquery != null)
            {                
                var originalSize = new string[] { originalquery.Count().ToString() };
                actionExecutedContext.Response.Headers.Add("originalSize", originalSize as IEnumerable<string>);
            }
        }
    }



Aug 22, 2012 at 10:00 AM

Hm, yes - or maybe I can use the new ODataOptions convention to get rid of the attribute (this only happens in one query right now)

However, I've come across a new problem - could you suggest a workaround?
http://aspnetwebstack.codeplex.com/workitem/342

Thank you!

Aug 22, 2012 at 10:15 PM

I have a fix that I am going to commit soon for issue 342. I will ping this thread once I commit it and is available on myget feed.

It wouldn't solve the enum issue though. The issue with enum's is that OData doesn't support enums. We are contesting the idea of mapping enums to strings and still have to iron out some minor details like what would the string look like in case the enum is a flag etc. This fix would take a bit longer, I am afraid. I would suggest opening an issue on issue tracker just to bump its priority. 

I would suggest using a string property as a workaround for enums for the time being.

Thanks,

RaghuRam.

Aug 24, 2012 at 8:58 AM

Thanks - I kind of went back to writing my own QueryableAttribute given that I don't need the full OData functionality right now and the API seems quite unstable at this time. I'll wait for a release.

Re the enum problem, you could temporarily encode it as a string and throw NotSupportedException if it's a Flags enum.