16

Resolved

OData does not support $select

description

This is the second most important odata commands after $filter. It's also trivial to implement because it's directly translatable to Dynamiclinq without alteration other than escaping it.

comments

HongmeiG wrote Aug 17, 2012 at 10:17 PM

We should move to use OData Uril parser in the OData formatter to parse the $select from Uri.

HongmeiG wrote Oct 25, 2012 at 11:56 PM

Moving this out to the next release.

Geminiman wrote Oct 26, 2012 at 12:46 PM

Seriously? The second most important odata command and you're moving it out to V3? I guess what they say about MS products is true... 3rd time's the charm....

richardgavel wrote Dec 21, 2012 at 8:35 PM

Based on http://blogs.msdn.com/b/alexj/archive/2012/08/21/web-api-queryable-current-support-and-tentative-roadmap.aspx, it sounds like there are several issues in integrating even a basic version of select:
  1. The select portion of the Uri needs to be parsed into the query options.
  2. The select portion of the query options needs to be applied to the source IQueryable so only those fields needed at the result are queried from the original data source (like the DB)
  3. The query options (or some other object containing that information) needs to be used by the formatter (since the action is still returning a IQueryable<T>) to only pull the relevant fields into the result.
This also means that if you don't use the QueryableAttribute but instead deal with the options manually, you would need to basically create a new T that only has those relevant fields populated, since the action method still has to return a IQueryable<T>, not the anonymous type resulting from the Select.

raghuramn wrote Apr 28 at 1:49 PM

https://aspnetwebstack.codeplex.com/SourceControl/changeset/8b65f6f102b9e336c605f24509bb8cf2d84b9694 introduces support for OData $select and $expand

Sign in to add a comment or to set email notifications