¿Existe un método general para verificar si una propiedad define soportada por un proveedor de Linq, especialmente OData?

Question

me funcionó con éxito la siguiente declaración con el Northwind.sdf en LINQPad:

from s in Shippers 
    select new 
{ 
    s.ShipperID, 
    s.CompanyName,  
    Count=s.ShipViaOrders.Count()  
} 

Al mismo tiempo, no pude correr una declaración similar con el Servicio Odata (http://services.odata.org/northwind/northwind.svc) en LINQPad:

from s in Shippers  
select new 
{ 
    s.ShipperID, 
    s.CompanyName,  
    Count=s.Orders.Count()  
} 

El error es "Construir o inicializar instancias del tipo <> f__AnonymousType0`3 [System.Int32, System.String, System.Int32] con la expresión s.Orders.Count() no es compatible.".

Sé que el servicio de OData es muy limitado en el soporte de Linq. Tengo soporte dinámico de declaraciones Linq en mi aplicación. En realidad, estoy tratando de migrar la fuente de datos de Compact SQL Server al servicio OData.

Así que tengo que lidiar con NotSupportedException de una manera general. En la actualidad, intento para comprobar la sintaxis de la propiedad definir antes de ejecutarlo, como

"s.Orders.Count() as Count" 

Pasó mi cheque, pero cumplió con NotSupportedException de OData.

¿Hay alguna forma de comprobar si un proveedor de Linq admite una definición de propiedad (por cadena o lambda)?

Cualquier sugerencia es apreciada.

Ying

Answer 1

Desafortunadamente no hay manera general, programática de comprobar si un proveedor de LINQ será capaz de traducir cualquier consulta dada. Normalmente, tendrá que recurrir a la documentación o (para estar seguro) realmente probar las consultas mientras lo hace.

Diferentes proveedores pueden, sin embargo, proporcionar algún mecanismo para generar alguna representación para la consulta, que puede utilizar para verificar si la consulta funcionaría sin tener que ejecutarla.

En el caso del cliente OData, puede invocar .ToString() en la consulta, y debe devolver una URL si puede procesar la consulta con éxito; de lo contrario, devolverá un mensaje de error que se parece a 'Error al traducir la expresión de Linq a URI: ...' (el mensaje de error real puede cambiar según el idioma del usuario, pero definitivamente no será un URI válido).

Answer 2

Lamentablemente, la única manera de averiguarlo es probando una consulta específica o mediante documentación si el creador del proveedor de LINQ ha proporcionado una lista detallada de lo que no es compatible.

LINQ en sí tiene una especificación muy flexible ampliamente definida por los métodos de extensión definidos en IQueryable/IEnumerable. La implementación de un proveedor de LINQ significa que debe implementar una traducción a través de la fuente de datos, p. LINQ to SQL traduce el árbol de expresiones expresado en una consulta LINQ en SQL que es entendido por un proveedor de base de datos. Cada fuente de datos tiene sus propias limitaciones que, en última instancia, regirán lo que se puede admitir, y asimismo cada proveedor de LINQ puede elegir implementar (o no implementar) cualquier método o comportamiento en particular.

Puede ser el caso de que esto es sólo una limitación del proveedor dentro LINQPad para tratar con OData - es posible que desee echa un vistazo a OQuery lugar y ver si se proporciona un mejor conjunto de capacidades para usted - echar un vistazo a http://beta.code.msdn.microsoft.com/OQuery-Building-OData-d2e75eed para los detalles y una descarga.