Selecting properties in a nested complex type does not work

[ificator]

Say I have a model where a Inner complex type is nested within an Outer complex (or entity) type, so a request without a $select would return:

{
  "outerProperty1": "foo",
  "outerProperty2": "bah",
  "inner": {
    "innerProperty1": "foo",
    "innerProperty2": "bah"
  }
}

According to the OData spec I should be able to write a query like ...?$select=outerProperty1,inner/innerProperty2 and have it return:

{
  "outerProperty1": "foo",
  "inner": {
    "innerProperty2": "bah"
  }
}

However what we actually get is an ODataException with message:

A path within the select or expand query option is not supported.

Assemblies affected

System.Web.OData

Reproduce steps

1. Make a request against a resource with a complex type property, and include a $select statement that references just one of the properties within that complex type.

Expected result

The request succeeds, and only the requested property from the complex type is returned.

Actual result

The request fails.

Additional details

Issue #837 mentions this issue, but it seems prudent to track it specifically.

[xuzhg]

BingAds has this requirement.

[daspek]

Further, we need a compact syntax to represent this. Let's say we have this object:

{
  "outerProperty": "foo",
  "innerProperty": {
    "inner1": "foo",
    "inner2": "bah",
    "inner3": "baz",
    "inner4": "qux"
  }
}

We don't want to do $select=innerProperty/inner1,innerProperty/inner2,innerProperty/inner3.
Instead, it should look like nested expand syntax: $select=innerProperty($select=inner1,inner2,inner3)

[brjohnstmsft]

@xuzhg Azure Search also has this requirement.

This seems to be a duplicate of #196 which as been open for a very long time. Any chance there will be traction on this soon?

FYI @robward-ms

[brjohnstmsft]

Also related: OData/odata.net#513

[ificator]

It would also be nice if there was a capability of filtering collection properties that aren't navigations:

$select=collectionProperty($filter=name%20eq%20'foo')

[brjohnstmsft]

@xuzhg I propose closing this issue since it is a duplicate of #196. If you agree, please close this.