The art of loose coupling

[picrap]

We are almost ready to remove driver references from all
DbLinq.<vendor> assemblies. This is a big step, since it will allow
to:
- use a different driver (I'm working daily with MF Oracle, and there
are at least 2 driver manufacturers, Oracle and Microsoft).
- be version independant (in a better than removing a specific version
requirement).
The changes are minimal:
- DataContext constructor with an IDbConnection doesn't change
- DataContext constructor with a DbProviderFactory is also allowed (I
need to see the specific case of Oracle ODP drivers who don't provider
a DbProviderFactory, but I think it can easily be done anyway).
By the way, http://linq.to/db documentation is very poor (I wrote it).
I'd like to have a discussion on DbLinq's roadmap, and we should
communicate on it.

[gmo...@gmail.com]

Bon Soir ...

1) Refactoring: Thanks for all this great work. But I want to ask: if
we are version-independent, how can we use features from specific
driver version? For example, only current alpha of Npgsql contains
bulk insert support (says Andrus).

2) can we do a code freeze by midweek, so that I can do a round of
testing, and create a new zipped release for March?

3) DBLinq roadmap: I just put some thoughts on the http://linq.to wiki.

[picrap]

1) Is this a special method call, or just different parameters? In
other words, it this driver API dependant or not? Of course, I don't
want to lose good performance because of conception. When I have
details, we'll try to figure out how to proceed.

2) Just give me a date and I'll keep quiet around it :). Usually all
commits are supposed to work without regression (I run all NUnit tests
on 4 databases).