ODATA - Query filter push down - asp.net-web-api

Question

I am new to OData, so any help would be appreciated.
I created a test ASP .Net Web API project to query data from SQL Server using OData and Drapper is used instead of EF. I found that the query filter does not get pushed into the query which is executed on the database.
q1. Does the push down work only with EF ?
q2. would OData work for any source which has a ODBC driver.
code snippet
public class InboundMetaDataController : ODataController
{
DapperContext db = new DapperContext();
[EnableQuery]
public IQueryable<InboundMetaData> Get()
{
return GetInboundMeta();
}
public IEnumerable<InboundMetaData> GetInboundMetaRecords()
{
var query = "SELECT Id, DataSource, Client, DataPath FROM Datalake.InboundMetaData ";
using (var connection = db.CreateConnection())
{
return connection.Query<InboundMetaData>(query).AsEnumerable();
}
}
public IQueryable<InboundMetaData> GetInboundMeta()
{
IEnumerable<InboundMetaData> qry = GetInboundMetaRecords();
return qry.AsQueryable();
}
}
public class DapperContext
{
private readonly string _connectionString = #"server=server1; database=test_db; Integrated Security=true; Encrypt=false";
public IQueryable<InboundMetaData> InboundMetaData { get; internal set; }
public IDbConnection CreateConnection()
=> new SqlConnection(_connectionString);
}
Thanks
Manoj George

Answer 1

The .Net OData implementation translates the incoming OData query into a LINQ expression tree. Unfortunately this can't easily be mapped into a Dapper query because it is not translated directly into an SQL query string.
q1. Does the push down work only with EF ?
So the direct answer is NO, this push down doesn't only work with EF, OOTB it will only work with a provider that supports IQueryable expression trees. otherwise you will need to manually parse the expression to SQL.
q2. would OData work for any source which has a ODBC driver.
You can make it work with any backend provider, but depending on the implementation you might have to do a lot of mapping or query building work yourself.
Technically, EF can be made to work with ODBC drivers, the ability to be vendor agnostic is often a reason to use EF in the first place. You can write your own custom implementation when needed, and for many ODBC drivers you might need to.
In regard to Dapper however, Dapper does not support IQueryable. Other users have found specific solution to this: Dapper, ODATA, and IQueryable in ASP.NET by iterating through the expression tree to build the SQL.
The problem with a solution like that, is that you've now manually replicated similar logic to what EF provides for you, and it is likely to take longer to execute than EF that has been specifically optimised for this type of processing. So the only argument that you might have to use Dapper has been invalidated.
In most implementations OData using Dapper will either have significantly reduced query features and possibly will not support aggregates or expansions, but will take longer to execute or will consume significantly more operational memory than if you had used Entity Framework as the ORM.
this is the line that first breaks the concept:
return connection.Query<InboundMetaData>(query).AsEnumerable();
At that point, before the request arguments are evaluated, the raw query without a filter is loaded into memory. .AsEnumerable() is the same as using .ToList() or .ToArray() in terms of moving the data execution into the API and out of the underlying data store.
This is the second anti-pattern in the same method:
using (var connection = db.CreateConnection())
{
return connection. Query<InboundMetaData>(query).AsEnumerable();
}
Because the DB Connection is closed before the controller method has completed execution, even if the output supported an IQueryable expression tree, the EnableQueryAttribute can only operate on the data that is in memory. If the query had not yet been executed, the whole call would fail because the connection has been closed before the query was executed.
For that reason, in OData controllers be tend to declare the DbContext or DbConnection for the lifetime of the request and do not dispose of it before the response content has been serialized.
If you're interested, I've written up a blog article that might help: Should I use Dapper?