There wasn’t going to be a 0.5 release of Simple.Data, but it started picking up a head of steam and I decided to push an extra release to help some people build some adapters and providers.


No more Reactive Extensions

The main change in this release is that I took out the dependency on the Reactive Extensions. It’s a bit of a shame, but the Rx assemblies are strongly-named, which means that when I build a Simple.Data release against what’s currently on nuget, and then they push a new build, it breaks everything the next time somebody installs the package. As Seb Lambla says in his OpenWrap presentation, strong-naming is anathema to package management, as well as just generally evil. I understand why they do it, but the actual implementation needs mending.

The only Rx functionality I was using was a trick for buffering data so that connections are closed as early as possible. I was doing this by pushing data from DataReaders through an IObservable and then using the Rx ToEnumerable method to cache the results. I’ve replaced this with a BufferedEnumerable type, which was interesting to write, and involved creating a Maybe<T> type to support it. .NET really, really needs a Maybe in the BCL.

NoSQL compatibility

A guy called Craig Wilson is creating a MongoDB adapter, and he ran into quite a few issues with the dynamic property name resolution. The code was using a special dictionary which “homogenized” keys as their values were set; essentially all non-alphanumeric characters were removed and what was left was down-shifted. This was fine for SQL Server, where the column names for CUD operations were resolved by interrogating the schema, but completely failed when used against a data store which has no schema. So the dictionary has been replaced with normal dictionaries using a custom IEqualityComparer implementation. While I was in there, I also optimised the Homogenize method, and created a new custom Dictionary implementation which only holds one copy of the keys for an arbitrary number of values; this saves quite a lot of memory when returning lots of rows.

Fewer internal types

In previous releases, I followed the minimal public API approach, and marked as internal anything I could. In order to facilitate testing, I added InternalsVisibleTo attributes to expose some stuff specifically to the SqlServer and SqlCe40 test projects. However, another guy is building a MySQL provider, and he rightly pointed out that all these internals made it impossible for him to copy the tests to use as a start point for his project. So I’ve made those things public.

It’s made me ponder the nature of internal and private and protected and so forth, and I might even manage a blog post on it at some point.

Roadmap update

So that’s where things are at for 0.5. The next feature release, 0.6, will appear at some point in March, bringing support for lovely complex queries with explicit joins, cross-table column lists, aggregates and so on. And hopefully there’ll be even more adapters and providers coming from the community (CouchDB and Redis have been mentioned); I’ll release minor updates to the 0.5 branch as and when necessary to support those things.


Mad props to Paul Stack for setting up a Continuous Integration and NuGet-deploying project on his TeamCity server.