timmartin / linqwrapper Goto Github PK

Ideally the user should be able to provide SQL to override any LINQ expression they wish to override. This has proved too tricky to get working at the moment, so there's a special case for Count(). Unfortunately, it doesn't detect the case where Count() is applied to a filtered result set (e.g. by Take()), so it will return the wrong value in this case.

I suspect that queries are being run unnecessarily in situations like the following:

Query<Foo> whatever = new Query<Foo>(...);
Foo x = whatever.ElementAt(1);
Foo y = whatever.ElementAt(2);

This needs to be tested, and if necessary fixed.

When instantiating a class that has members of object type, it should be possible to recurse to another object builder, and create members of that class from the DB data in the same way.

ADO queries are pretty useless without the ability to bind parameters into them.

When the query is executed, it leaves a data reader open on the connection

We already have support for building SQL with Skip() and Take() limits built in, but we can't currently parse them as LINQ expressions. This is a bit of an obvious gap.

The original state was that we created DB connections and passed them into the QueryProvider, and that never disposed of them. The problem appears to be that the standard way of doing LINQ is to have one instance (or a small number of instances) of the query provider, and hold all the query-specific stuff in the query. However, the way I've got things at the moment we need a new provider per query, and that means that providers have to be disposed of.

For the moment I've modified Query<> to be disposable and to dispose of it's provider when it is itself disposed, but this doesn't seem in keeping with how LINQ is supposed to work. This needs more thought.

The Cast() expression expects to be applied to a SQL execution expression, so it fails if you do

Query<> query = ...
query.Cast<Foo>().Cast<Foo>();

If you do a Count() query, then do a subsequent query without a count (e.g. a ToList()), the Count() has already transformed the SQL so that the full rows are not returned.

We should support applying the Cast() operator to queries, which should not in itself cause the SQL to be executed.

At the moment there is no support for non-trivial expressions in the select clause, which will be ignored, causing the wrong type to be returned. This ought to be fairly easy to implement, and is relatively important since it's easy to write code that compiles but crashes spectacularly when run

This method has grown by accretion, and I really didn't understand what I was doing when I first wrote it. It's probably time for a refactor.

Currently, the SQL generation assumes that all joins will be expressed in the form

SELECT foo
  FROM bar, baz
 WHERE bar.id = baz.id

To use this library in anger it will have to support

SELECT foo
  FROM bar
  JOIN baz ON baz.id = bar.id

in some way better than just putting the entire join clause in one call to AddFromClause()