Some API changes and enhancements
After the slow-down in development caused by all that InMemoryAdapter stuff, there were a few important things I needed to address quickly. One of these will have broken third-party adapters (but not providers) so let’s talk about that one first.
var db = DatabaseHelper.Open(); var user = db.Users.Get(1); Assert.AreEqual(1, user.Id);I’m not really sure why Get wasn’t already there, to be honest. Part of the problem is that it requires a new abstract method internally, and until adapter authors implement that method, their users are stuck on <0.11, which I try to avoid where possible.
For the ADO adapter, Get will use the table’s primary key to construct the query (once; it’s then cached internally, no worries about performance). For the MongoDB adapter, I’d expect it to use the built-in id value that Mongo assigns to all records. Somebody is working on an OData adapter, for which, e.g., Customers.Get(1001) will resolve to the /Customers(1001) URL.
Get is supported in the InMemoryAdapter, but you’ll have to configure the key(s) for each table:
var adapter = new InMemoryAdapter(); adapter.SetKeyColumn("Test", "Id"); Database.UseMockAdapter(adapter); var db = Database.Open(); db.Test.Insert(Id: 1, Name: "Alice"); var record = db.Test.Get(1); Assert.IsNotNull(record); Assert.AreEqual(1, record.Id); Assert.AreEqual("Alice", record.Name);
Trace configurabilityThe ADO adapter has been writing all generated SQL to the Trace output at the point of execution for a while now. While this is often very useful, I’ve had a couple of people ask if I could make it turn-off-and-on-able, so I have. You can do this in two ways:
Database.TraceLevel = TraceLevel.Off;
<?xml version="1.0" encoding="utf-8" ?> <configuration> <configSections> <sectionGroup name="simpleData"> <section name="simpleDataConfiguration" type="Simple.Data.SimpleDataConfigurationSection, Simple.Data"/> </sectionGroup> </configSections> <simpleData> <simpleDataConfiguration traceLevel="Error"/> </simpleData> </configuration>
(Gotta love XML.)
ADO SQL output will happen with the trace level set to Info, Warning or Error.
More ADO connection controlI occasionally see how Simple.Data performs compared to other ORM/micro-ORM tools, using the PerformanceTests project from Dapper. I was running this through the other day, and I realised that Simple.Data was losing a lot of time opening and closing connections, while the other test cases were mostly using an open connection for the duration of the test. I’ve had a few comments that they’d like more control over the connection, or that Simple.Data is too aggressive in closing connections, so I decided to improve my standing in the Dapper smack-down and hopefully help some real people out too.
Start using an open connection like this:
SqlConnection connection = Program.GetOpenConnection(); ((AdoAdapter) db.GetAdapter()).UseSharedConnection(connection);
And stop using it again like this:
And that’s it. In my performance test project (which is in the solution on Github), this knocked 20-30% off the runtime, with 500 FindById operations taking ~80ms, versus ~50ms using plain ADO.
I’ve also tried to tone down the aggression a little when it comes to closing connections, doing it as soon as possible, instead of (occasionally) before.