I’ve just pushed Simple.Data 0.8.0 to NuGet. The version hike here is mainly because of a fairly big change in the way the core communicates with adapters to run servers, although there is a new feature that I really like; more on that in a bit.
From now on, I’m going to follow semantic versioning. This 0.8 release is intended to be the last one that is going to change the "internal API" that adapter authors have to implement. It also represents the full public API that will be in the 1.0 release. The only task now is to document that API and fix any bugs or performance issues that come up.
I’ve started doing some proper profiling of the code using ANTS Profiler; so far, it hasn’t thrown up anything hideous, or any obvious paths for optimization, but there will probably be a couple of "best practice" notes that come out of it. I’ve yet to do any memory profiling, so there’s still that to look forward to.
I’ve also run NDepend across the code, and there are a few things I maybe need to clean up (and a few things it needs to shut up about), but generally speaking, it’s pretty good quality. The main issue so far is tracking down junk methods and types that aren’t used any more due to the various brutal refactorings that have gone before.
Both these tools are excellent, and I’m intending to use them as a matter of course on all my projects from now on. Watch this space for some posts on my experience with them during this phase of Simple.Data development.
The final metric I’m focused on is code coverage, which I’m measuring with a combination of dotCover and Mighty Moose. I’ve added nearly 200 new tests since I started this exercise, and quite a few of them highlighted some minor issues which I’ve fixed. It’s not just for show! For the entire project code coverage is now up around 85%, which is good, but still not quite good enough.
Aside from all the code stuff, I’m getting around to some proper documentation, too.
That new feature: “Magic Counting”
A feature I’ve been asked for a couple of times is the ability to run multiple statements in a single database call, and in both cases, the underlying requirement was the same: getting the overall count for a query in conjunction with paging. A couple of weeks ago I was reading a post on Ayende’s blog where he showed some sample RavenDB query code that included a call to a method called Statistics, which dumped out various bits of info about the query into a special class, and I really liked the way it did that, so I borrowed the idea. Now, in Simple.Data, you can do this:
[sourcecode language="csharp"]Future<int> count;
var q = _db.Customers.QueryByType("Valued")
// q returns 10 records
// count.Value is set to total number of records matching criteria[/sourcecode]
The Future<int> type is a very lightweight wrapper type that doesn’t have its value set when you get it back from that out call, but will have a value after the query has executed (whether by calling ToList, or just starting a foreach). The count and the paged result set are retrieved in a single database call (assuming the provider supports compound statements; SQL Server does, SQL Compact doesn’t, for other providers YMMV), which means performance is good and your DBA should be happy.
While I’m here, if you missed the brief mention on Twitter, I’ve knocked together a GUI tool – inspired by LINQPad – which lets you test out queries against your data store and provides some basic auto-complete functionality! I’m hoping that this will help to compensate for the lack of IntelliSense™ in Visual Studio; I’m actually finding it a pretty useful tool in its own right. It dumps out all the SQL that gets run in a separate tab so you can keep tabs on it, too.
It’s very basic at the moment, but I’ll be using it to help me write the documentation so I’ll polish it up as I go. If you want to play, best to build from the source from Github.
One last thing
I did an interview with Dot Net Rocks, about Simple.Data and my thoughts on simple, minimal development frameworks generally. It’s here if you like that sort of thing.