On May 4, 2011, at 5:33 PM, Giacomo Tesio wrote:
> Acutally I'm currently focused on the Epic.NET project.
> It's a framework to build complex domain driven applications, but it has some problems in common with dblinq: we are designing a query provider and we are going to use re-linq; we need to have multidatabase support (but for example we don't need datamapping for our entities).
And this is why the re-linq folks got in touch with me. Having a "standardized" cross-DB interface to re-linq/etc. would be wonderful. I had suggested following System.Data.Common.CommandTrees for the standardized interface (as that's what EF uses), but (sadly) we found that CommandTrees made all the constructors private/internal. :-(
They also determined that the CommandTrees data structures basically codified/mirrored SQL Server, e.g. (from private email discussing with the re-linq folks):
> E.g., the most efficient way to do paging on MS SQL is to use a
> BETWEEN condition where you compare row numbers against page limits.
> Because EF does not support this, the command trees also donít support
> this and just use a TOP clausefor the upper bound.
This largely killed my idea of doing much with CommandTrees.
> This mean that I could help you too, as I did worked on the dblinq code base (up to 0.19 version).
> From my POV, dblinq used to miss good development documentation: no overall vision and so.
> I did remember it took days to dive into the code.
> What has changed from 0.19?
Nothing has changed. :-)
> Anyone sketched the architectural vision about the project?
I've sketched out some ideas in the 0.19 release notes:
See the "What needs work" section, specifically the "Code cleanup: offloading databases provider support" bullet.
> BTW is it still in the mono codebase?
A copy is in mono's codebase, but this is just an occasionally (manually) synced copy of what's in DbLinq svn.