...and $select!

This is a great feature to add. However, we need to close down the current release. We can revisit this in vNext.

FYI, the thread on $select in the forums has code that you can adapt to implement any of the missing functions for odata outside of actually having to alter the mvc.net source code for those that need a hack work around for this.

Thanks Geminiman, that was a pretty tough read wading through the unnecessary aggression. I'll take it you were pointing to the Action Filter example? Unfortunately I need access to the Dynamic Queryable code base to inject the any/all parsing which would not be possible. Nor would it be possible from an Action Filter as it would involve replacing the entire queryable stack.

PeteGoo: My that wasn't agression. That's frustration that MS doesn't actually use it's tools to build tools until after V1. Once they finally start using them internally then they realize all of the major problems, and that's why it takes until V3 to get it actually working an usable.

As for your assertion that Any/all is not possible with the way that I went about it, I tried it myself and implemented basic Any/all using the action method without too much trouble in about 20 minutes. Works like a charm.

But I'm sure that you're content using an incomplete solution that hasn't been fully thought out for basic use cases, so I'm sure you'll wait for someone at MS to tell you when you need these basic features...

Geminiman, Web API is not for full-featured OData support; its support is limited to just our four filter types (and even those are not fully implemented). For full featured OData, you should use WCF Data Services.

Brad: I've heard this before, however for the use cases presented as what it's supposed to be used for, $select is absolutely required for any SPA that is going to be released publicly because it won't scale without it. (I've said this many times.) We're told over and over again never do Select * on a database, and yet every sample you have for SPA not only does SELECT * it does SELECT * recursively making it N times worse.

It is absolutely to be expected in an SPA that you're going to list data, and then click on an item in the list to get the details. That list will pull from multiple tables 99 times out of 100.

Thus SPA and Web API is NOT READY for any release quality application and won't be until such time as $select is supported and it allows projections. And to my point, MS would know this if MS tried to build a real app that was going to be released to the general public using Web API and SPA.

In fact this is the core issue with all MS dev tools and OSes etc. (and why Windows 8 is going to be very not well received along the lines of Vista for anything but tablets) You don't use the tools to build stuff until after version 1 is released. You then fix all of the major stuff you found that prevented you from releasing a product built on it and get your product out and then release it to us later as V2. This gets rid of the issues you noticed when you were building your own stuff, but doesn't help everyone. It's almost ready but not quite. V3 is released once someone inside MS realizes that the issues people brought up in V1 were real and need to be fixed but that MS ignored until they went to build their own stuff with it, and voila you have a stable and usable product finally at V3.

If you don't believe me, look at Entity Framework, or .NET Framework for that matter, or VB back in the good old days. or Win NT/2000/XP.

Hence why I hacked in $select. I can get around the rest, it won't be pretty but it works and I don't have to deal with the monster that is WCF with all of it's overhead and overly complex setup that breaks at a drop of a hat etc.

And fortunately I can attribute my way to no magic instead of using the "by convention" mess that is forming in the MVC team using Get, Update, Insert and Delete methods and making assumptions (which you should never do) that are unreadable and unexpected behavior unless you happen to know the convention, which you should never need to know to read and update someone's code.... but that's a commentary for another day.

Yikes. This is an issue list, not a discussion forum. Send me a PM if you want to chat. In the mean time and in the spirit of open source software, would you mind sharing your implementation on git/gist or similar?

Thanks for the clarification Brad.

PeteGoo, nice work!
I receive an exception when apply an "any" query against null collections. Do you believe this "as designed" or that the query provider should assume the any query evaluates to false?

Probably a bug. I'll take it we would expect Any and All to return false in these cases?

@PeteGoo,
I would expect false.

FYI, MS has seen the light and my point about Web API taking over for all but the most complex tasks requiring WCF... the latest nighties have oData completely removed while they're working on integrating the oData query engine from RIA Services directly into WebAPI.

This means that you're going to get $select, $all, $any, and $expand and every other part of the spec in WebAPI shortly. Whether it's done for release I don't know, but it doesn't really matter... just use the nightlies like I do (well right now no because there is no odata but...)

We now have support for Any() and All() in our nuget packages for odata (Microsoft.AspNet.WebApi.OData).