Db4o on .NET and Mono

After failing to get a cross-platform sample of NHibernate/Sqlite going, I decided to try out Db4o. This is for a simple, local object persistence layer anyhow, nothing more than a local cache, so db4o sounded perfect.

The initial DLLs for 7.4 worked beautifully on .NET but ran into problems on Mono. Apparently db4o imports FlushFileBuffers from kernel32.dll if your build target is not CF or mono. And in its call to FlushFileBuffers it uses FileStream.SafeFileHandle.DangerousGetHandle() which it not yet implemented under Mono, resulting in this exception:

Unhandled Exception: System.NotImplementedException: The requested feature is not implemented.
  at System.IO.FileStream.get_SafeFileHandle () [0x00000]
  at Sharpen.IO.RandomAccessFile.Sync () [0x00000]
  at Db4objects.Db4o.IO.RandomAccessFileAdapter.Sync () [0x00000]
  ...

I found this page on the Db4o site, which suggested just falling back to FileStream.Handle. However, that for me just resulted in this:

Unhandled Exception: System.EntryPointNotFoundException: FlushFileBuffers
  at (wrapper managed-to-native) Sharpen.IO.RandomAccessFile:FlushFileBuffers (intptr)
  at Sharpen.IO.RandomAccessFile.Sync () [0x00000]
  at Db4objects.Db4o.IO.RandomAccessFileAdapter.Sync () [0x00000]
  ...

So, i simply defined MONO as a compilation symbol in visual studio and rebuilt it. I figure the only time this code will run on Windows is during testing, so treating it as mono is fine. And that did solve my issues and i now have a DLL for db40 7.4 that works beautifully across .NET and mono from a single build.

Being a Linq nut, I immediately decided to skip the Native Query syntax and dive into using the Linq syntax instead. Which worked great on mono 2.0.1, but unfortunately on the current Redhat rpm (stuck back in 1.9.1 lang), the Linq implementation isnt' quite complete and you get this:

Unhandled Exception: System.NotImplementedException: The requested feature is not implemented.
  at System.Linq.Expressions.MethodCallExpression.Emit (System.Linq.Expressions.EmitContext ec) [0x00000]
  at System.Linq.Expressions.LambdaExpression.Emit (System.Linq.Expressions.EmitContext ec) [0x00000]
  at System.Linq.Expressions.LambdaExpression.Compile () [0x00000]
  at Db4objects.Db4o.Linq.Expressions.SubtreeEvaluator.EvaluateCandidate (System.Linq.Expressions.Expression expression) [0x00000]
  ...

But falling back from this syntax:

var items = from RosterItem r in db where r.CreatedAt > DateTime.Now.Subtract(TimeSpan.FromMinutes(10)) select r;

to the NativeQuery syntax (with delegates replaced by lambda's): `db.Query`

var items = db.Query<RosterItem>(r => r.CreatedAt > DateTime.Now.Subtract(TimeSpan.FromMinutes(10)));

It's still a fairly compact and straight forward syntax, so until i finish setting up my own Centos mono RPMs, i'll stick to this syntax.

I need to run db4o through some more serious paces, but I like what I see so far.