Client - inefficient query generated from projection with only expansion about odata.net HOT 3 OPEN

Unfortunately, /People('russellwhyte')?$expand=Friends($select=FirstName)&$select=Friends is not a valid request because Friends, being a navigation property, cannot be used in a $select statement. A workaround could be to either $select a known value like UserName, or just directly calling /People('russellwhyte')/Friends.

from odata.net.

Sorry - I don’t think that’s correct. Your reference TripPin service on data.org accepts it’s just fine and returns a payload respecting the intended projection. Could you please check again. OData V3 client behaves correctly in this regard and issues a select part letting the server know what to return - and that is not everything.

from odata.net.

Hi @corranrogue9
According to the protocol documentation at odata.org navigation properties are perfectly valid in $select. Please check https://docs.oasis-open.org/odata/odata/v4.01/odata-v4.01-part2-url-conventions.html#_Toc31361040 where it is stated that:

If the select item is a navigation property, then the corresponding navigation link is represented in the response. If the navigation property also appears in an $expand query option, then it is additionally represented as inline content. This inline content can itself be restricted with a nested $select query option, see section 5.1.2.

The ABNF also states that navigation properties are allowed as select property, please check https://docs.oasis-open.org/odata/odata/v4.01/cs01/abnf/odata-abnf-construction-rules.txt. Where the $select is described as:

select = ( "$select" / "select" ) EQ selectItem *( COMMA selectItem )
selectItem = STAR
/ allOperationsInSchema
/ [ ( qualifiedEntityTypeName / qualifiedComplexTypeName ) "/" ]
( selectProperty
/ qualifiedActionName
/ qualifiedFunctionName
)
selectProperty = primitiveProperty
/ primitiveColProperty [ OPEN selectOptionPC *( SEMI selectOptionPC ) CLOSE ]
/ navigationProperty
/ selectPath [ OPEN selectOption *( SEMI selectOption ) CLOSE
/ "/" selectProperty
]

Also please note that the OData Client for OData V3 did include the navigation property in the $select - correctly letting a V3 service know that it shouldn't return all primitive and complex properties for that specific path when they were not part of the projection. OData V3 client (Microsoft.Data.Services.Client 5.8.5) produces this request for the same query (on V3 the $select is not wrapped inside the $expand):

/People('russellwhyte')?$expand=Friends&$select=Friends/FirstName
On OData V3 client - if we have the expanded Firends navigation property selected projectionless the request will include the navigation property in the $select letting the service know that it should return all propeties from the Friends navigation path, but none of the properties from the root path People('russelwhyte'). So a V3 query like...

            var q = from p in ctx.People
                    where p.UserName == "russellwhyte"
                    select new Person
                    {
                        Friends = p.Friends
                    };

Will produce a request like:

/People('russellwhyte')?$expand=Friends&$select=Friends/*

As the V3 protocol had all selects sitting on the root level there would be a select on the root path in such situations. The V4 protocol has the select properties nested within the $expand path. This leads to this "bug" where the root path will become projectionless in theses scenarios where the materializer clearly have it projected and all other properties than Friends on the root path is ignored.

If there are other ways to resolve this issue than including the navigation property Friends in the root $select, then that is also fine - as long as we can agree on that we have a performance issue here with queries like this. Our model have rather large entity types (having hundreds of properties) - this issue is really bad for developers doing queries like this - they have all the projections in place minimizing the response payload to only include what they actually need - but the actual payload is wrong as the projection is missing on the root path.

Thanks for looking into this issue
Uffe

from odata.net.