Have a $metadata only command for a select. This would return the full metadata for a select, but no actual data.
We need the metadata because we then provide the user with what properties they can make use of from a select. When providing that metadata in a prompt, we do not need any data at that point in time.
This should be on the server so that a program written to handle version 3 will still provide the correct metadata if the server is version 4 and the uri passed in uses commands that are new to version 4 and therefore would not be recognized by a client side parser reading the uri and using the EDM to build up the metadata for that uri.
For example, a case with a $expand that will have main entries, each with 2 feeds, where one of those feeds has entries with feeds. Being able to test this where each level returns 5 - 7 entries, but pages them 2 entries at a time would make it much easier to test paging on the client side.
The same for returning every PayloadKind - at present we can't find an example that returns a Collection. Anyone writing a client app needs to get a sample service with this to test that it handles this case correctly.
As far as I am aware currently, WCF data services does not allow users to hide columns.
I recommend that we allow restricted access to columns. Example if table1 has columns C1, C2, C3. and we use WCF Data Services and Entity Data model to expose data in table1 as Odata. I want to allow some users (of my wcf dataservice)to view/access only Columns c1, c2 but not c3.
Currently this is not possible in WCF Data Services i think. Please do email me if i am wrong in my understanding.
Propagate any existing comments in the EDM to the DataService $metadata so that the client proxy can put that into the comments of the generated properties, giving us meaningful intellisense about the classes and properties in the client.
Allow setting of the .AllowWriteStreamBuffering property of the request. Right now data services always internally sets it to true during save changes no matter the value that is set beforehand. This is not good as it forces entire requests to be buffered client side. This has a really negative impact if trying to stream BLOB media (like a video) as a media linked entity.
OData is clained extension to Atompub and its main format is of Atom. However, OData does not enforce its feeds(entityset) Atom syndication compliant, and feed readers at large (like google reader) usually cannot render Odata feed properly. Should OData feed be a valid Atom syndication - with Odata extensiton like content/property of course, all feed reader would be able to dispaly it decently, given its content type if atom+xml.
It would be nice if the .Expand method support the same syntax than the .Include method of Entity Framework.
If WCF Data Service has a .NET client, going over .NET Client API, communication between service and that client could be additionaly optimized. I think that this would be very helpfull.
Using WSDL to define service contracts will make it easier for non-Microsoft platforms to consume the services and lead to greater industry acceptance.
Almost all applications need authentication.
This would need to be done via EDMX - some method to wire it into the partial class, or if not auto-generated, the POCO class.
Get the Web API and WCF Odata support in sync.
ASP.Net web API supports v5.2 of the WCF Client libraries - and it was released on the same day as the WCF 5.3 libraries. Way to make it hard to pass a request from an API controller to a WCF Data service.
The .net client part of OData presently builds under 3.5. Please continue this and release it as a 3.5 build. There are a very large number of apps out there that are still using the .net 2.0 CLR and for OData to run on them, it must be 3.5.
I don't know how many people use partial classes to augment the generated classes in the DataServiceContext file from DataSvcUtil.exe. I am asking that a new option be added to DataSvcUtil.exe to have a file that sits next to the generated one to allow people to add their own custom entity properties.