[Closed] WCF Data Services Feature Suggestions

This web site is no longer being monitored by the Microsoft OData team. Visit http://odata.github.io/odata.net/ for current information on the Microsoft OData Stack for .NET and where to submit feedback.

Welcome to the WCF Data Services feature suggestion list. Find out more information about Data Services at our MSDN page.

If you have questions, need help or find a bug in Data Services, visit our forums.

How can we improve WCF Data Services?

You've used all your votes and won't be able to post a new idea, but you can still search and comment on existing ideas.

There are two ways to get more votes:

When an admin closes an idea you've voted on, you'll get your votes back from that idea.

You can remove your votes from an open idea you support.

To see ideas you have already voted on, select the "My feedback" filter and select "My open ideas".

Enter your new feature idea

(thinking…)

Enter your idea and we'll search to see if someone has already suggested it.

If a similar idea already exists, you can support and comment on it.

If it doesn't exist, you can post your idea so others can support it.

Enter your idea and we'll search to see if someone has already suggested it.

I have a service operation defined on my service that is exposed via the metadata. When I use the Add Service Reference gesture to create client proxy code, the proxy code should include methods that call those service operations (for instance, if I have a service operation with the signature "IQueryable<Customer> GetCustomerByCity(string city)", I should have a corresponding client method that calls that service operation and materialized the result

While this ask is purely a feature ask, we currently do not generate methods on the client to call service operations. As part of the OData v4 client library, we plan to modify our code generation from using CodeDom to a T4 template. Best case scenario, in the same time frame we will make that T4 template publicly available and anyone can modify it to their heart’s content. Worst case scenario, we will either add this feature ourselves down the road or make the T4 template public as soon as we can.

Currently, service operation requires parameters passed in query string even in case of POST request. Batch request can avoid the limitation of query string length, but it still has limitation of System.Uri class (64Kib) on client and server sides of custom data service.
So, we can't serialize complex data and pass it as input parameter of service operation without small size limitation.

WCF DS recently (5.0?) introduced the awesome feature of properties being collections of complex objects. This makes great sense for e.g. orders/orderlines and persons/addresses, since each orderline/address is owned by its parent (order/person) and does not need to be an entity. For some backends this enables great performance increase in some scenarios.

The typical theoretical example of using complex types is an Address property of some entity. In the real world an address typically contains a city and/or a country. Although the address is unique, the city and/or county probably would be shared between several entities. Thus we would like to model the city and the country as entities rather than complex types.

But since we are not allowed to have navigation properties on complex types, we can not model the address as having a city and/or country. And then the use case of order/orderlines and persons/addresses fails...

For simple complex properties (not collections) a common workaround would probably be putting the entity references on the owning entity instead of in the complex property. For collections of complex objects this is not an option.

And since complex properties should be nothing more than imposing structure on the entity ("grouping properties"), we should be able to to use the same toolset when constructing the complex types as when constructing the entity types.

A wild guess is that this limitation comes from Entity Framework and relational databases where the complex type is typically mapped to a table and the navigation property would create a foreign key between the complex type table and the referenced entity. When building custom providers, we are not limited to relational databases though. Just guessing...

What do you think?

WCF DS recently (5.0?) introduced the awesome feature of properties being collections of complex objects. This makes great sense for e.g. orders/orderlines and persons/addresses, since each orderline/address is owned by its parent (order/person) and does not need to be an entity. For some backends this enables great performance increase in some scenarios.

The typical theoretical example of using complex types is an Address property of some entity. In the real world an address typically contains a city and/or a country. Although the address is unique, the city and/or county probably would be shared between several entities. Thus we would like…