locked
Feature requests. RRS feed

  • General discussion

  • Like you need more.  But here are some that have been on my mind:
    1) Like we can do /Users(1) by key.  We should be able to do /Users(Name='abc') to return a unique record from any column that has a unique index.


    2) Allow service operations as alternate endpoints in a heirarchy. Instead of /Users(1)/products, I could use /GetUser(1)/products
       or /Users(1)/GetProducts(1..30). Note how we can use service operations down from root. Also needs to be a way to refer to Parent inside the service operation.
       So in prior example, GetProducts method could know what user was selected and select products accordingly maybe also using other invariants.


    3) Like #2, if a service operation returns a single result, you should be able to link to the children in uri query. Example /GetUsers(1)/Products


    4) How about ranges as shorthand for a longer filter - /Users(1..30) or /Users(CreatedDate:[1/1/08]..[2/1/08])


    5) Way to query method help (i.e. Summary, Remarks, etc) on methods and entities.


    6) Way to dynamically, at runtime, add service operations to the service side. This is more of an agile request. Instead of stopping, creating a webget, compiling, Updating the client service reference, creating a client proxy method, etc.
       Maybe even an easy way to add service operations using a Powershell functions or scripts.


    7) Some easy way to see the generated expressions and sql on the server side without having to start up Sql Perf.


    8) Way to get the passed Expression inside a service operation.
       [WebGet]
       public IQuerable<Users> GetUsers()
       {
           // Get and use client query expression here as an IQuerable. Or modify it. Or debug it.
           var iq = Current.Request.Query;
           return iq;
       }


    9) Way to add POCO objects (and graph) to the Rest schema without having to crack open xml or model files. Such as add a Property to the DataService that returns a collection.


     

    Wednesday, November 12, 2008 5:40 AM

All replies

  • Hi William,

     

    Thanks for the suggestions ! If you haven't already, you can log these at:

    http://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions

     

    cheers,

    Jade

     

     

     

    Friday, July 8, 2011 11:18 PM
    Moderator
  • Hi,

    Definitely log these to the site mentioned by Jade above. Just a few comments:

    #1 - how would the server know which of these are unique and thus allowed? Should it blindly run the query and fail if it returns more than one result?

    #5 - note that the client only sees the $metadata from the service. Not all service operations must be C# methods (custom providers are free to implement them in different ways). So I guess you're asking for a way to query more information about the service operation from $metadata, right? The ability to put that information into the $metadata is more or less part of this feature request: http://data.uservoice.com/forums/72027-wcf-data-services-feature-suggestions/suggestions/1012631-annotations?ref=title. The way to query that might be solved for example by this: http://www.odata.org/blog/2010/4/22/queryable-odata-metadata. (Note that queryable metadata can be implemented through custom providers today).

    #6 - Custom providers can do this today, but I guess you're asking for some kind of tooling support for the C# method service operations. Not sure how this should work though, the C# code for them needs to be recompiled anyway, but ASP.NET does this automatically even today. And the client side code gen doesn't support service operations yet anyway.

    #7 - That's pretty much described here: http://blogs.msdn.com/b/vitek/archive/2010/03/03/data-services-expressions-part-2-the-query-root.aspx. Note that if the underyling IQueryable is EF or LINQ to SQL based it can get you the SQL it will run (one of them has it as ToString, the other has a method, I never remember which one is which).

    #8 - You can do this by wrapping the IQueryable you return from the service operation just like in #7. It describes how to wrap an IQueryable so that you get a chance to do something with it before it gets executed. So your service operation would return the wrapped IQueryable as it does today, then the WCF DS adds the client query onto it and then it executes it. The wrapper allows you to intercept the query before it gets executed, at which point you can see the whole thing and modify it any way you want.

    #9 - Isn't this already supported through EF POCO and CodeFirst?

    Thanks,

     

     


    Vitek Karas [MSFT]
    Tuesday, July 12, 2011 8:59 AM
    Moderator