Yesterday programmer Noah Hart announced a port of SQLite to C#:
I am pleased to announce that the C# port is done to the point where others can look at it.
Unfortunately the code was taken offline almost immediately afterwards, thanks to the intervention of the author of SQLite, D Richard Hipp:
Noah, you are welcomed, even encouraged, to take the source code to SQLite and translate it in any way you want and do whatever you want with it. But you need to make it abundantly clear to everyone on your site and in the comments of your source code that your code is not the original SQLite … SQLite is a registered trade mark. If I don’t defend the trademark, then I could lose it. So, I really do need to insist that you not use the name "SQLite" for your product.
The reason given is that Dr Hipp does not want to receive support requests for the port, though the intervention is a little surprising since there are other 3rd party adaptions out there that do use the SQLite name, though these generally modify or wrap the original code rather than porting it completely.
Still, Hart has taken it in his stride and it looks as if the code may be back soon under the name sqlsharp – a Google code project with that name has been created. I hope this is the name since I suggested it, though it is rather an obvious one and I might not have been the first.
Why the interest? First, it’s always interesting to compare languages. Currently, Hart says his executable compiles to 528kb vs 506kb for the native version, and performs 3-5 times more slowly (results in rows per second):
Test | SQLite3 C# | SQLite3 |
Inserts | 300K | 1300K |
Selects | 1500K | 8450K |
Updates | 60K | 300K |
Deletes | 250K | 700K |
Although that may seem disappointing, SQLite is remarkably fast so even 5 times slower is still acceptable in many contexts; and there are no doubt many possibilities for optimisation.
What’s the point? Hart says it was a C# learning exercise, which is fair enough. Others are hopeful for a local database manager for Microsoft Silverlight, writing to isolated storage. Competitor Adobe AIR includes SQLite in the runtime, as does Google Gears.
Silverlight may a stretch for Hart’s port. Silverlight does not allow platform invoke or code marked as unsafe; and while there are apparently only a few p/invoke calls I’m guessing there may be many unsafe sections since the original SQLite makes heavy use of pointers.*
Although Silverlight is an implementation of the .NET Framework, it does not include the System.Data namespace. It does include System.Linq.
There are a few other efforts at creating a local database manager for Silverlight, including McObject’s Perst, db4o (work in progress), and Silverlight Database which works by persisting XML.
*Update: the project has now been published as csharp-sqlite, which is an excellent name; it looks as if Hipp relented to some extent. Now that I’ve seen the code I find I’m wrong about unsafe sections. In fact, I added C#-Sqlite to a Silverlight project and it failed to compile with a mere 53 errors, many of them related to file locking – possibly less necessary in isolated storage? A Silverlight port looks feasible.
As much as I like the name “sqlsharp” there are already at least 3 projects out there with this name. Maybe something a little more unique would cut down on long-term confusion?
@Solomon – fair point, now is the moment to shout!
Tim
What really needs to be done is for Microsoft to include SQLite in Silverlight.
FYI: hSql has aleady been ported to silverlight http://conceptdev.blogspot.com/2009/07/sql-in-silverlight.html
Try EffiProz Database (http://www.EffiProz.com).
EffiProz is a database written entirely in C#. comprehensive SQL support including Stored Procedures, Triggers and Functions. Ideal for embed in .Net applications. Support Silverlight 3 and .Net compact framework as well
Include Visual Studio ad-in, ADO.Net provider, Entity Framework provider, etc.