Feature complete!

I am very, very happy to announce that, with the latest release of Simple.Data – 0.7.1 – to NuGet, it is essentially feature-complete, at least as far as my personal road-map for it is concerned. There are still a couple of things to implement which will help adapter authors out, but for end-user-developers, it covers most of the things we need from a data-access framework. That is not to say I am not open to feature requests, particularly those that are for blatantly obvious things which I have half-wittedly omitted. The 0.7 series of releases will focus on improving performance, tidying up some of the code, and improving test coverage to catch any naughty bugs that are hiding out in there. The last release in the 0.7 series will effectively be the final 1.0 Release Candidate.

Before I embark on this final stretch, I’m going to take some time to create proper documentation so that all you lovely people out there can really put Simple.Data through its paces. Because of the dynamic nature of the framework, it lacks the discoverability that most .NET libraries get through IntelliSense, so it’s important to have some good quality docs to make up for that. I’m going to try and use Github’s wiki facility to build and maintain, particularly because community contribution would be greatly appreciated, but if that comes up short in any way, I’ll look for a better solution.

Anyway, never mind all that:

What’s new in 0.7.1?

There’s a fair selection of new features in this release, and one breaking change which I’ll get out of the way first:

Count and CountBy are now GetCount and GetCountBy

In order to support the Count operator within queries, I’ve had to change the name of the Count methods on the table object, so these are now called GetCount and GetCountBy:

[sourcecode language="csharp"]db.Posts.GetCount(db.Posts.Rating >= 4); db.Posts.GetCountByTag("simpledata");[/sourcecode]

"Having" clause support

Queries now support a Having method, which represents the clause of the same name in SQL selects. You can use all the aggregate methods that are supported in column selection lists: Min, Max, Avg, Sum and Count.

[sourcecode language="csharp"]// Find all posts without comments db.Posts.All().Having(db.Posts.Comments.CommentId.Count() 0);[/sourcecode]

Math operators

Expressions can now include simple mathematical operators: add, subtract, multiple, divide and modulo.

[sourcecode language="csharp"]// Find all animals with an odd number of legs db.Animals.Find(db.Animals.LegCount % 2 1);[/sourcecode]

Bulk Inserts and Updates

You can now pass lists (or IEnumerables) of dynamically- or statically-typed objects to the Insert, Update and UpdateBy methods. In the case of Insert, when using the Ado adapter, you get back a new list of objects with any database-assigned default values such as identity values or timestamps. The Update methods just return a count at the moment, but I might change that to return the updated records.

(One thing that definitely may be a possibility by 1.0 is an Upsert method, which would take a list of objects, insert the new ones and update the existing ones.)


Guids are once again supported for SQL Server's "uniqueidentifier" type, and probably the equivalents in the other supported ADO databases.

A null-equality expression in Simple.Data criteria will become an "IS NULL" expression in the SQL generated by the ADO adapter.

Various other glitches and peccadilloes have been spotted and terminated with extreme prejudice. However, I have reason to believe that there may be more glitches, and even another peccadillo or two, at large in the code. If you encounter one, please either fork the code, kill the creature and send me a pull request, or, if it's particularly fierce and you don't want to get near its teeth, just open an issue on Github with some sample code that will draw it out into the open so I can shoot it.

Go for it

At this point, I am happy to recommend that you can use Simple.Data in production systems. Many people are already, with no reported problems. Obviously your mileage may vary, but I am confident that any speed-bumps or potholes (or rogue metaphors) that you run across will be relatively minor and easy-to-fix (except the metaphors, which are tenacious and systemic).

I'll post here again once I've made a start on some comprehensive documentation. In the meantime, if you need any help, the first place to try is the Google group/mailing list; the second is the Github site, and the third is either me on Twitter or, potentially, the creator of your particular adapter or Ado provider.