This project is read-only.

Mysql and/or Postgres?

Mar 30, 2011 at 10:30 AM


Thanks for this interesting project. Any chance to have it working for Mysql and/or Postgres one day?




Mar 30, 2011 at 1:21 PM


MySql is already supported out of the box provided that you have the MySql Connection/Net  ADO.NET driver.

It can be downloaded from this location

Adding support for PostgreSql should not be a problem at all, although I have awaited this until someone actually asks for it.


Bernhard Richter





Apr 4, 2011 at 8:33 AM



My apologize, I meant SqlLite instead of Mysql. Any chance for it? Just for info, how long does it take you to "implement" compatibility with a new kind of RDBMS?

Apr 4, 2011 at 9:20 AM

Hi again!

"how long does it take you to "implement" compatibility with a new kind of RDBMS"

Given that the target DBMS contains a feature set that is "convertable" to the API exposed by DbExpressions, I'm looking at one long day to implement the provider and have all the tests pass.

I am however, dependent upon a native ADO.Net provider for the target DBMS. Seems like the System.Data.SqlLite provider is the closest available although it seems only available for .Net 2.0/3.5.

Since SqlLite does not implement all the features of a "full fledged" DBMS, I would have no choice but to throw a lot of NotSupportedExceptions, but I guess that would be okay in this case.

You would still be able to use the library as long as you stay away from advanced string/datetime and numeric functions not available in SqlLite.

What do you think? Is it still worth the effort?


Bernhard Richter




Apr 5, 2011 at 1:45 PM
Edited Apr 5, 2011 at 1:46 PM

Regarding support for SQLite

I have looked into the situation with SQLite and how it might be possible to implement a provider for it in DbExpressions.

As mentioned before, SQLite supports only a subset of the functions (string/datetime/numeric) that we see present in most larger database management systems.

In order for the DbExpressions library to have any value, it should implement the API exposed by DbExpressions for every provider.

Failing to do so will result in an incompatibility with other providers and this would defeat the whole purpose of this library in the first place.

But we are not completely lost yet. There are ways to overcome these limitations.

Functions not available in SQLite can be implemented in C#/VB.Net by deriving from the SQLiteFunction class and decorate the class with the SQLiteFunctionAttribute.

There are a few problems here as well because the assembly that implements these custom functions must have a reference to the System.Data.SqlLite assembly.

This may cause problems when the System.Data.SqLite library is updated to a new version.

This could also be solved by using Reflection.Emit to create the functions at runtime and hence not creating such a strong dependency to a specific System.Data.SQLite assembly.

Anyway I will continue to do investigate on this.



Bernhard Richter

Apr 5, 2011 at 2:45 PM

I also imagine that they will always be functionalities not implemented by some DB types. Example: we use partitions in our DB, which is very Db-specific and not implemented de facto by sqlite. So, in a few cases, to have some methods throw a NotSupportedException or a NotImplementedException would not be irrelevant.

Thanks for your time and effort on that subject!