Deserves its own post, even though I’m about to write the 0.11 one.

This release took much longer than I would have liked, mainly because I bit off more than I could chew. I had a requirement to provide poly-fills that implement query operations against in-memory datasets, on behalf of adapters for data-stores that don’t support certain operations. Think aggregates, grouping and so on. At some point, it occurred to me that this would make it really easy to create an in-memory adapter which would just have all query functionality implemented by these poly-fills.

Aside: From very early on, Simple.Data has had the XmlMockAdapter which could be used for providing a quick and dirty database for test environments. At the time I wrote that, I wasn’t totally confident in the Simple.Data model, so a way to instantiate that data without using the API seemed important. Since then, of course, the API has become much more stable and I’ve gained confidence, so it seems perfectly OK to use it to set up the test data as well as consume it. Consider XmlMockAdapter deprecated.

Simple.Data.InMemoryAdapter

The InMemoryAdapter lives directly in the Simple.Data namespace in the Simple.Data.dll assembly from the Simple.Data.Core package. It is a first-class component, because testing is a first-class concern.

You can use the adapter like this:

Database.UseMockAdapter(new InMemoryAdapter());
var db = Database.Open();
db.Test.Insert(Id: 1, Name: "Alice");
var record = db.Test.FindById(1);
Assert.IsNotNull(record);
Assert.AreEqual(1, record.Id);
Assert.AreEqual("Alice", record.Name);

That UseMockAdapter method is now directly on the Database class. After calling that, all subsequent calls to any of the Database.Open methods will return a database using that adapter.

Any tables you reference in the database will be “created” if they don’t already exist. Internally, the tables are just lists of dictionaries. Any data you insert will retain its CLR type, so the adapter can handle byte arrays and so on quite happily.

Joins are supported:

var adapter = new InMemoryAdapter();
adapter.ConfigureJoin("Customer", "ID", "Orders", "Order", "CustomerID", "Customer");
Database.UseMockAdapter(adapter);
var db = Database.Open();
db.Customer.Insert(ID: 1, Name: "NASA");
db.Customer.Insert(ID: 2, Name: "ACME");
db.Order.Insert(ID: 1, CustomerID: 1, Date: new DateTime(1997, 1, 12));
db.Order.Insert(ID: 2, CustomerID: 2, Date: new DateTime(2001, 1, 1));

var customers = db.Customer
    .FindAll(db.Customer.Orders.Date < new DateTime(1999, 12, 31)).ToList();
Assert.IsNotNull(customers);
Assert.AreEqual(1, customers.Count);

And most query operations work OK.

YMMV: This is probably not perfect, but it was stalling other development so I took the decision to release it. So far in my own projects it has not caused any problems; I’ve had one reported which is fixed in 0.11 (more on that in the next post).

Bug fixes and such

There were a bunch of fixes for various issues in 0.10, most of which were contributed by Richard Hopton, who has also released an ADO provider for Sybase SQL Anywhere.

I know it’s early for New Year resolutions, but I’m going to share this one now partly so I don’t forget in six weeks.

I buy a lot of media. I have an entire 6′x3′ bookcase full of technical books, most of which are out of date by at least one version. There’s a cubic hectare of Blu-ray and DVD boxes lying around the place, and I’m pretty sure there are boxes of CDs (remember those?) in the loft somewhere. Probably half the available storage space in my house is taken up with things which would actually fit on a few terabytes of hard disk.

It’s not like everything in the house isn’t already digital. We’ve got a 160GB iPod Classic, iPhones, iPads, Kindles, three laptops, an Xbox 360, a PS3 (with a 320GB HD), a 50Mbps internet connection, and on Saturday we bought an Apple TV.

It’s ridiculous. It has to stop. It ends, starting in January. From then on, where a digital purchase option is available, I shall avail myself of it. I will invest in a home server with a few TB of storage on mirrored drives; I’m thinking of the Lacie 5big Network 2, which will take up to 10TB. Then I can “back up” my movie collection to that, and install iTunes on it for music streaming. Paper books will go to charities and libraries; if I want to read any of them again, I’ll buy them in ebook format. Magazines through Newsstand and papers through the Times iPad app.

Now, I just need Sony and Microsoft to distribute all PS3 and Xbox games digitally, and I need never darken the door of another shop. Not that I do anyway. All this crap comes from Amazon.

I just sent this to our recruiter (our only recruiter, so please don’t bother if you’re not him), and it occurred to me that it might make an interesting mini-post, so here it is, copied and pasted from my email.

The main thing we look for is strong core programming skills, ideally in C# but will also consider Java and C++ programmers. The interview will include technical questions about Object Oriented programming and whichever skills the candidate claims to have.

Web development is the second most important thing for us these days. Again, there will be questions about web applications, ASP.NET fundamentals and so on.

The third thing we expect is database skills, and I’ll ask questions about database design and SQL. I don’t want people who only know ORM abstraction layers.

Obviously the level to which the questions go varies according to the level we’re interviewing for, but the basics of all three would be covered for all levels.

My big bugbear is when I ask a question which the candidate’s CV implies they should know the answer to, but it turns out they don’t.

Any code questions are asked and answered on the whiteboard, so individuals who rely totally on IntelliSense are in trouble.

If you’re looking for a developer role with a great company in Windsor, UK, and the above doesn’t put you off, please get in touch!

This is a Public Service Announcement

TL;DR

Simple.Data returns dynamic objects. You don’t have to use statically-typed POCOs unless you want to.

And in full for those without Attention Deficit disorders

I just caught this post on Google+, about using Simple.Data with MongoDB. (I’m really pleased that there’s a MongoDB adapter, because (a) MongoDB is awesome, and (b) it’s the poster child for the fact that Simple.Data is not exclusively an RDBMS-targeting solution. The adapter works really well, although some query operations don’t make sense in MongoDB; I’m working on some code for Core which provides polyfills for any operations which adapters might not be able to interpret meaningfully, such as grouping and aggregates and so forth.)

Anyway, back to the main point of this short post. The comments from Jak Charlton about static typing made me realise that there is potentially a fundamental misunderstanding about what Simple.Data actually does, and a belief that it requires static POCO types to work. It doesn’t, but I haven’t made this clear enough, so sorry about that, and this is me rectifying that situation.

So this misunderstanding probably arises from the fact that most of the demo apps and blog posts that have been written do use POCOs, doing things like this:

User user = db.Users.FindByEmail(email);
VerifyPassword(enteredPassword, user.Password, user.PasswordSalt);

That code works, but in terms of clarity it hides a step in the process. If I split it into two steps, it becomes clearer:

var record = db.Users.FindByEmail(email);
User user = record;
VerifyPassword(enteredPassword, user.Password, user.PasswordSalt);

The first line creates an object of type SimpleRecord, and the type inferred for var is dynamic. (SimpleRecord is very similar to the BCL ExpandoObject type, but with some data-access-specific intelligence.)

The second line performs a kind of “implicit cast” of the dynamic SimpleRecord object to the static User type. (SimpleRecord handles this by overriding the DynamicObject.TryConvert method, if you’re interested.)

The Very Important Thing that I want you to take away from reading this post is that the second line is not required. This code will work every bit as well:

var user = db.Users.FindByEmail(email);
VerifyPassword(enteredPassword, user.Password, user.PasswordSalt);

Here, user will be compiled as dynamic, created as a SimpleRecord instance, and will return values for the Password and PasswordSalt properties when asked. You just won’t get IntelliSense™ for the object.

Other things you can do with these dynamic objects is pass them to your View for rendering, or bind to them in WPF applications. If you don’t want the “statically typed noose dragging you down” (and personally I really don’t), then Simple.Data is your new best friend.

Tonight’s movie

will be Pitch Black. A group of marooned space travellers struggle for survival on a seemingly lifeless sun-scorched world.

That is all.