SQLite C# port raises hopes for a Silverlight local database manager

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.

VN:F [1.9.18_1163]
Rate this post
Rating: 0.0/10 (0 votes cast)

Related posts:

  1. Sun gets a database manager, but Oracle owns its InnoDB engine
  2. Proof of concept: C#-SQLite running in Silverlight
  3. Updating the world’s most widely deployed SQL database engine: welcome to SQLite 4
  4. A Silverlight database application with image upload
  5. C#-SQLite now published

5 comments to SQLite C# port raises hopes for a Silverlight local database manager