Searching the web, we can find plentiful examples of various ORMs (nHibernate, EF, LinqToSql, etc.) that implement but don’t actually support the full IQueryable<T> interface, throwing NotSupportedExceptions when they encounter something they don’t like, such as LinqToSql and SkipWhile. My question is this: why do ORM providers opt to throw a NotSupportedException instead of letting certain query operators (that do not translate well or at all to the target data source) trip a query execution and then let Linq to objects handle the rest?
I understand that some heavy physical resource usage could occur as a result, but if IQueryable<T> instances were truly swappable, would we not be better off?
One of the purpose of the IQueryable<T> interface is also to allow differed execution of the query, i.e., the functions applied to the collection are not actually applied but converted internally, in the case of LINQ to SQL for example, in an SQL query (a string).
If there is no way of expressing the given function in the source, then you can’t support the operation, and you better have the programmer know that by throwing the NotSupportedException. He might then decide to switch to a specific data structure and carry on from there, but at least he knows what he’s doing.
3
Well, because
- You would lose control of the query process, and
- You would get an unexpected, and inaccurate, result.
The NotSupportedException is there so that you, the developer, can be notified of the unsupported feature. You can then re-work your query in some way to get the result you want, without using the unsupported feature.
8
I think the main reason is that such behavior could have very unexpected performance. Namely, if you tried to skip over most of some table, the query would need to load most of the table (or at least the relevant columns).
When the choice is between something that is unexpected and reporting error that can be easily fixed (by adding AsEnumerable() before the TakeWhile()), I think it makes sense to choose the latter.
If you don’t like this, you could create your own IQueryable wrapper, that behaves exactly the way you want: if the underlying IQueryable throws NotSupportedException, call the equivalent method from LINQ to Objects (by using AsEnumerable()).
5
Because of it’s complexity. If query throws NotSupportedException that probably means you query is extremely complex. And as such, it would be really hard to separate what can be run over DB and what must be done in-memory. In simplest way, you just fetch the whole table or maybe half of the DB, thanks to joined records. And you must be crazy to think that is good idea, especially when it happens without you knowing. Implementing such detection algorithm would be quite complex, probably even more complex than implementing query feature itself.
Also, implementing IQueryable is quite complex in itself (as proven by NHibernate devs), so they probably haven’t had time to implement this specific feature of whole complex query system.