One of the recent project I am sort of involved is an ongoing effort to implement System.Data.Linq.dll, a.k.a Linq to SQL, with DBLinq project. DBLinq is designed to be like Linq to SQL, but opens the door to support more database systems than SQL Server.
The Bootstrap
When I was asked to get involved in Linq to SQL work in this spring, I drew a rough sketch to implement S.D.Linq.dll based on DBLinq. In the middle of May, Jiri Moudry, one of the core DBLinq hacker, was also starting to work on Mono support. Occasionally we were in the middle of Google Summer of Code (SoC) program (beginning phase) and there was a student who was interested in Linq to DB. The student, Pablo Iñigo Blasco, became the core hacker of this effort. In fact, at first I was rather cautious about it: I haven't drawn good-enough picture of how to get every party involved yet, and especially I definitely needed to talk with DBLinq hackers.
Actually, at first I wrote System.Data.Linq API implementation as a wrapper on top of DBLinq. At that time, DBLinq was designed to be dependent on System.Data.Linq.dll. I thought that I had to resolve this issue (as it is a circular dependency), but it turned out that Pascal Craponne, another core DBLinq hacker, explained their plan to implement System.Data.Linq API by themselves(!) I quickly discarded my implementation and started rethinking about the SoC project with Pablo, which now became much hopeful than before. After all, it started off so well.
DBLinq changes for "Mono_STRICT" mode
When the SoC project started in June, the DBLinq team was busy on "sugar" expression tree implementation. So, I asked Pablo to start from writing samples for DBLinq which could be later ported to use S.D.Linq API. He did awesome job.
In the middle of June, as Pascal finished the first sugar work, we started to talk about Mono integration. Including the purpose to clean up the code, they introduced #if MONO_STRICT code.
Our need for the API was however somehow messy: we had to eliminate extra API members from the resulting System.Data.Linq.dll. And DBLinq itself is extensible enough to allow developing third party "vendor" API and hence exposing a lot of extra members. I had messy concern; I was afraid of getting final System.Data.Linq.dll cutting extra database support than SQL Server, since SQL Server is the only public vendor in System.Data.Linq API. (The concern didn't go away until recent talk.)
After a lot of discussion, Pablo came up with his nice Roadmap to build both DBLinq full and Mono's System.Data.Linq from the same code base, and he quickly made it.
Pablo continued and continues contributing to DBLinq project. I'm extraordinary glad to see his achievement and continuous participation to the project. I thank to all those guys who made it happen :)
Trying it out
Currently we still haven't integrated DBLinq source into our mcs tree yet. Though, I often create System.Data.Linq.dll based on their effort. For now, I have an archive: System.Data.Linq-20080930.zip - replace existing mcs/class/System.Data.Linq with the expanded directory, renamed as System.Data.Linq. And then run make (you need make clean).
As the end of the Soc project, we needed a working sample code for review. So I asked Pablo to cook some instruction, and he wrote it. With the latest svn version the test somehow hit NotImplementedException in "sugar" now, but it'd show you current DBLinq / System.Data.Linq implementation status.
A problem is that the current System.Data.Linq.dll contains only support for SQL Server, so you have to use it for now.
Help DBLinq effort
Yes, there is not a few things that need to be implemented. DBLinq project guys are calling for contributions. If you are interested in joining the effort, that'd be awesome. It helps Mono too.
Other than DBLinq (and System.Data.Linq) itself, there are also some interesting stuff to help this effort: ASP.NET LinqDataSource control in .NET 3.5 SP1 uses Linq to SQL, so implementing it will help dogfooding System.Data.Linq API. DynamicData may also help dogfooding, but that needs some extra love (it looks dependent on LinqDataSource). There's a lot of fun stuff here.
Leave a comment