This is an appeal for standardizing nomenclature and cleaning the
architecture.
At present, in order to do anything useful, 4 layers are involved:
User Code, what the user writes, e.g. from user in db.Users....
DbLinq, e.g. DataContext, what the user interacts with.
Database Driver, e.g. DbLinq.Sqlite.dll, responsible for
generating SQL which is sent to the provider.
Database Provider, e.g. System.Data.SQLite.dll, responsible for
interacting with the actual database.
(RFC: Are these names appropriate? If not, what names should be used?)
The benefit to this is code centralization: many databases have multiple
different providers but accept the same SQL (e.g. Mono.Data.Sqlite vs.
System.Data.SQLite, System.Data.OracleClient vs. Oracle.DataAccess,
SqlClient vs. SqlCeClient, etc.). This is even more useful to prevent
tying a driver to a particular provider version, allowing the provider
to be easily updated to later versions without modifying the driver.
Which brings us to the problem: parts of the current DbLinq vendor
architecture tie the driver and provider layers together, specifically
DbLinq.Vendor.Implementation.Vendor.TypeToLoadData(), used by
Vendor.CreateDbConnection().
(Then there is the the issue mentioned at [0], in which I consider
parsing all types in all assemblies within the current AppDomain to be
an abomination, which is related to this.)
So, in code, the problem:
string connectionString = "DbLinqProvider=Sqlite;Data
Source=Northwind.db3";
var dc = new DataContext(connectionString);
var dcq = from p in dc.GetTable<Product>() where p.ProductName == "Pen"
select p.ProductID;
var cmd = dc.GetCommand(dcq);
Console.WriteLine("# Command Type: {0}", cmd.GetType().FullName);
// Prints "# Command Type: System.Data.SQLite.SQLiteCommand"
This is a problem specifically for Mono, as (1) Mono will be bundling
all the drivers into System.Data.Linq.dll, (2) I want Sqlite to be
supported (simplifies testing, etc.), and (3) System.Data.SQLite.dll
will not work under Mono (mixed mode assembly), so I need to use
Mono.Data.Sqlite.dll. Since the current DbLinq.Sqlite.dll explicitly
loads System.Data.SQLite.dll, this causes things to break rather badly
when executing under Mono.
The question: How do we fix this?
First, what exactly is broken? Specifically, what is broken are the
DataContext constructors which take a string connection string
parameter, and use the connection string to deduce both the driver and
the provider, so this impacts only the DataContext(string) constructor.
If you use the DataContext(IDbConnection) constructor, then the original
IDbConnection instance is used for creating subsequent IDbCommand
instances, so all is well.
Proposed Solution: I would suggest making the connection string
parameters follow the naming scheme outlined above, and use a
DbLinqDriver parameter to specify the DbLinq driver to use (Sqlite,
Oracle, etc.). I would then use a DbLinqConnectionType parameter to be
the Assembly Qualified Type that should be used to create the
IDbConnection instance. This type must have a constructor taking a
single string parameter. The current DbLinqProvider parameter would be
removed (or kept as a synonym for DbLinqDriver, but I think down this
path leads confusion.)
This would allow the above code to work as expected while only changing
the connection string to
"DbLinqDriver=Sqlite;DbLinqConnectionType=Mono.Data.Sqlite.SqliteConnection,
Mono.Data.Sqlite; Data Source=Northwind.db3". What I'm less sure about is
whether assembly qualified type references including version information/etc.
will be valid SQL connection strings; I'll need to look this up.
Making this change would permit removing Vendor.GetProviderTypeName(),
thus removing the implicit dependency the driver makes on the provider.
Thoughts?
- Jon
[0]
http://groups.google.com/group/dblinq/browse_thread/thread/76c943f6e02735e7/4e2ea660f68e006f?lnk=raot#4e2ea660f68e006f
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DbLinq" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/dblinq?hl=en
-~----------~----~----~----~------~----~------~--~---
