locked
Where(string predicate) RRS feed

  • Question

  •  

    How come rest client has no string predicate overload for dynamic where like the Ado.net client has?  It would seem this would be useful for the same reasons it is useful to the other client.
    Wednesday, September 3, 2008 3:27 AM

Answers

  • ADO.NET Data Services client Linq implementation does not support projections beyond very simple ones that return the entire entity (identity projections) or a single property.  We did this because all other types of projections are not supported via the URI syntax and we didn't want to implicitly do a client side operation.  To get this sort of functionality, simple call AsEnumerable() on your query before doing the projection.  This solution works for all operations not supported by the ADO.NET Data Services Linq implementation.  Note though, this makes all these operations client side operations and can have huge perf issues depending on the scenario.

     

    As for the string filter for when you call Where.  In the code snippet above, you are actually calling the esql query builder method (the query syntax is specifically esql). esql is currently not supported in V1 of ADO.NET Data Services, but something we are considering for V2.

     

    You can get support for string based filters if you via the dynamic linq query library.  For more info, check out here:

     

    http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

     

    Again, same restriction as above.  The predicate must be of the kind supported by the underlying URI syntax of ADO.NET Data Services.

     

    Andy

    Wednesday, September 3, 2008 6:03 PM
    Moderator

All replies

  • Hi,

    The client has string based parameters for uri queries ,
    ex:

    Code Snippet
    dsContext.Execute<T>(new Uri("Your Hand Crafted URI goes here") )

     

     

    Did you mean string parameters for Linq queries ?
    If you can give us a couple of scenarios where you want string parameters, it would help.

    Wednesday, September 3, 2008 4:38 AM
    Moderator
  •  

    Thanks Phani.  I mean be able to use dynamic string expressions in the where clause like you can in Object Queries in the EF.

     

    Console.WriteLine("Dynamic Expressions:");

    SocialEntities db = new SocialEntities();

    var q = db.Users.

    Where("(it.Tag='one' OR it.Tag='two') AND it.UserID<2").

    Select(u => new { u.UserID, u.Tag });

    foreach(var u in q)

    Console.WriteLine("{0} {1}", u.UserID, u.Tag);

     

    I think it is a more natural way to filter then having some "?$filter=...." syntax and is more linq-ish.

    Also having string in the Select() allows other things you can't get otherwise.

    http://msdn.microsoft.com/en-us/library/bb298787.aspx

    Wednesday, September 3, 2008 6:39 AM
  • ADO.NET Data Services client Linq implementation does not support projections beyond very simple ones that return the entire entity (identity projections) or a single property.  We did this because all other types of projections are not supported via the URI syntax and we didn't want to implicitly do a client side operation.  To get this sort of functionality, simple call AsEnumerable() on your query before doing the projection.  This solution works for all operations not supported by the ADO.NET Data Services Linq implementation.  Note though, this makes all these operations client side operations and can have huge perf issues depending on the scenario.

     

    As for the string filter for when you call Where.  In the code snippet above, you are actually calling the esql query builder method (the query syntax is specifically esql). esql is currently not supported in V1 of ADO.NET Data Services, but something we are considering for V2.

     

    You can get support for string based filters if you via the dynamic linq query library.  For more info, check out here:

     

    http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

     

    Again, same restriction as above.  The predicate must be of the kind supported by the underlying URI syntax of ADO.NET Data Services.

     

    Andy

    Wednesday, September 3, 2008 6:03 PM
    Moderator
  •  

    Thanks Andy.  Projections would be way nice in future as I am sure is a popular feature request.  As far as Where goes... As a random dev, I vote to have Where support dynamic string predicates like the EF can, even if it is its own special implementation to parse the Where string and build the uri query.

     

    BTW - nice work folks. appreciate it.

    Saturday, September 6, 2008 4:39 PM
  • It acutally isn't that hard to build up the expression for the predicate dynamically.  The logic is nearly equivalent to what one would do with strings - you are just using expressions.

    Sunday, September 7, 2008 2:32 PM
    Moderator