[Mono-dev] Announcing DbLinq 0.19

[Jonathan Pryor]

The DbLinq team is proud to announce the release of DbLinq 0.19,
following the venerable DbLinq 0.18 release from September 2008.

DbLinq is a reimplementation of System.Data.Linq.dll for use with SQL
servers in addition to Microsoft SQL Server.  Support is provided for:

      * Firebird [0]
      * Ingres [1]
      * MySQL [2]
      * Oracle [3]
      * PostgreSQL [4]
      * SQLite [5]
      * SQL Server [6]

Note that not all servers are supported equally: some tests will pass
under some database backends while failing under others.  I maintain the
SQLite and SQL Server backends, while the community handles the others.

Fixes from the 0.18 release are legion (regressions are unknown), and
include:

      * "Green" unit tests for Release builds, making it easier to find
        regressions.
      * Integration with Mono to serve as the System.Data.Linq.dll and
        sqlmetal.exe implementations.
      * Partial support for DbMetal to generate entity definitions from
        SQL Server databases.
      * DbMetal improvements for SQLite, SQL Server. 
      * Generate partial methods within entity types for OnXxxChanging()
        and OnXxxChanged() methods. 
      * Fix DataContext.Transaction support.
      * Implement DataContext.ObjectTrackingEnabled.
      * Fix DataContext change tracking for object graphs. 
      * Numerous EntitySet<T> fixes. 
      * Support queries containing constant boolean expressions, e.g.
        db.Customers.Where(c => true && c.City == "Paris").
      * AttributedMetaModel lazy initialization. 
      * Support queries within generic methods. 
      * Support method calls within Queryable.Select() selectors. 
      * Support calling IEnumerable<T> extension methods on EntitySet<T>
        instances within Queryable.Select() selectors. [8] 
      * Fix SQL Server paging support (.Skip()/.Take()).
      * PostgreSQL support improvements.

Thanks to:

        ACluk90, admin at yuniti.com, ashmind, atsushieno, bryanlivingston,
        crippledcanary, dev.null.nix, e.kotlyarov, emanuele.aina,
        ericksonqua, federico.digregorio, giacomo, gmoudry, goshe.moshe,
        jcarrascal, jonmpryor, kobruleht2, Matthew.C.Snyder, netcade,
        pibgeus, picrap, six.douglas, thomas.glsr, Toncho11

What needs work?

DbLinq is by no means complete, and by no means on the same footing
as .NET's Linq to SQL. For those interested in helping, here are some
activities:

      * DbLinq bugzilla: http://code.google.com/p/dblinq2007/issues/list
      * DbLinq unit tests:
        http://dblinq2007.googlecode.com/svn/trunk/src/DbLinq/Test/
              * Search for [Explicit] to find tests that are known to
                fail under DbLinq and need fixing for .NET Linq-to-SQL
                compatibility.
      * Code cleanup: over-abstraction.  Lots of types come in
        interface/implementation pairs, even when there is only one
        implementation and the type is internal to the library.  Such
        "over abstraction" complicates maintenance by increasing cast
        sites or requiring that new members be added in more places.
      * Code cleanup: under abstraction.  Other places (especially the
        expression tree parsing library, Sugar) have explicit type
        checks and casts riddled throughout, instead of abstracting the
        check into base-class virtual members that derived types can
        override (thus removing the type checks and centralizing logic).
      * Code cleanup: string removal.  Currently, the interface between
        DbLinq's core and the database provider code is based on
        strings, building the SQL up piecemeal as strings.  If the DB
        provider wants to perform any "elaborate" changes on it (e.g.
        SQL Server Take/Skip code), string parsing/manipulation is
        required.  This is evil.
      * Code cleanup: offloading databases provider support. Only DbLinq
        provides (and supports) DbLinq's LINQ/databases interface.
        Consequently, only DbLinq provides providers for databases.  I
        would like to drop DbLinq's current interfaces and replace it
        with Entity Framework's System.Data.Common.CommandTrees (or
        something very similar).  Ideally, this would allow us to e.g.
        use SQLite's own Entity Framework provider and reuse it as-is
        (or with minor changes) so that DbLinq can use SQLite, instead
        of DbLinq needing to maintain its own SQLite provider library.
              * This would also help bootstrap any potential Mono Entity
                Framework support.  It wouldn't be core Entity Framework
                support, but it would allow sharing more code between
                DbLinq and any such Entity Framework support.
              * It should also bring sanity to the current string-based
                boundary between the DbLinq core and the database
                provider code.

 - Jon

[0] http://www.firebirdsql.org/
[1] http://www.ingres.com/
[2] http://www.mysql.com/
[3] http://www.oracle.com/
[4] http://www.postgresql.org/
[5] http://www.sqlite.org/
[6] http://www.microsoft.com/sqlserver/
[7] http://groups.google.com/group/dblinq/browse_frm/thread/4242411770d568f4
[8] This means that constructs such as this are supported:

	from e in db.Employees select new {A = e.Orders.ToList()};

Note that this support under SQL Server currently requires
'MultipleActiveResultSets=true' support, which Mono's
System.Data.SqlClient is lacking.  I'd love a SqlClient-level fix for
this; see https://bugzilla.novell.com/show_bug.cgi?id=556835