After reading the 'Custom Data Service Providers' documentation of the ODataProviderToolkit from microsoft, I end up a little confused where to start. My intention is, to have a OData server for a table in the database, which structure is unkown during compile time. This we can not change.
For now, we update our model from the database every time this table is reconfigured by the user, compile and update the OData service. This is not suitable.
The documentation 'Part 4: Basic Read-Only Untyped Data Provider' explains the implementation using Linq to objects. The implementation is very complex, creating IQueryable data providers.
My question: Shouldn't the requested implementation be simple and straight forward using standard classes which provide a TSQL dataprovider and IQueryable interfaces?! Using TSQL datasource, SQLConnectionString, c# EF 4 with linq to sql...
I just don't know how to put this all together.
Or is it really necessary, that I implement all these expression tree related methods like ExpressionVisitor, GetSquenceValueMethodInfo, etc.?
Thanks in advance.
I tried this about half a year ago (Web API OData 2). What I did was to create the EDM model on the fly for every request and set it in a custom OData Route constraint. In the controller I returned EdmEntityObjects of the type corresponding to the current request. I expected that returning an IQueryable would do all the magic of filtering, but it failed saying that the operation is not supported. We (timecockpit) have since gone implemented an QueryNodeVisitor for the OData AST, which is substantially less complicated than a full IQueryable implementation. We don't support all functions, but only those that are available in our custom query language (TCQL).
I haven't checked recently if the newer OData Web API supports filtering on typeless EdmEntityObjects. Even if, one would still pass filter criterias to the SQL database In order to not load all entities into memory before filtering.
I doubt that directly forwarding the query to SQL using Linq-2-SQL works and I would expect that at least some rewriting of the query (e.g. for adding permission checks) is necessary in every but the most trivial applications.