I just pushed the latest version of Simple.Data to NuGet. No huge changes, but a couple of improved extensibility points in the core library, and a change to the way the packages are organised.
More flexible connection handling
Simple.Data is pretty aggressive about how it uses, and especially closes, ADO database connections. These things are expensive resources to hold onto on a web-server; you want to grab one from the pool, get what you need and then get it back in the pool so the next request can use it. So every use of a connection is wrapped in a using statement. Which is great, but then somebody created a SQLite adapter, and one of the really cool things to do with a SQLite adapter is to use an in-memory database for running your BDD tests. And when you close the connection to an in-memory SQLite database, you drop the database.
Anyway, rather than change all the connection handling in the Simple.Data.Ado code, we decided to use a Delegating Wrapper pattern. In this instance, this is a class which implements IDbConnection, and takes an instance of IDbConnection, and just delegates all the calls. But it marks its implementation methods as virtual, so you can derive a concrete class from it and override just a few methods – in this case, Open, Close and Dispose. I added a base class for doing this as it is the kind of thing that might be needed by several provider authors.
This came from a request on the mailing list, asking if the named connections in the <connectionStrings> section of web.config (or app.config) were supported. They weren’t, because I’d forgotten about them, and that was bad, so I fixed it.
This means that you can now have a section in your config like
connectionString="Data Source=SQL2008;Initial Catalog=SimpleTest;User ID=SimpleUser;Password=SimplePassword"
And you can call Database.OpenNamedConnection(“Test”) and that will open up that connection.
At the moment that’s as far as it’s gone, but this also provides a way for more than one database engine to be in use in a single application. The providerName attribute can be used as the MEF contract name in the provider libraries, and that gives us a nice, easily extensible and standardised way for people to create new providers.
So if, for example, you have created a MySQL provider, you need to add an additional Export attribute to your IConnectionProvider implementation, specifying “MySql.Data.MySqlClient” as the contract name. 🙂
In the next release (0.5.5) this will be the standard way in which ADO providers are resolved, although it’ll fall back to the old (and deprecated) mode if necessary.
The other important change is that the Simple.Data.Ado.dll assembly has been put into its own package, which is depended on by the provider packages. When I first pushed Simple.Data up to NuGet, it only supported ADO-based connections, so it made sense for the ADO adapter to be in the Core package. But now, there is a MongoDB adapter, and talk of adapters for CouchDB and Redis, and none of those have anything to do with ADO, so why would you want it cluttering up your packages folder?
If you are the author of an AdoAdapter provider (e.g. MySQL and SQLite) you now need to make Simple.Data.Ado a dependency of your NuGet package.
If you are the author of an Adapter, just leave the dependency on Simple.Data.Core; now, users of your package will not have the Ado assembly installed.
Supported store round-up
I’m going to finish release posts with a quick roll-call of the supported databases and other data-stores. For release 0.5.4, there is support for:
- SQL Server 2005 and up
- SQL Server Compact 4.0
- MySQL 4.0 and above
- SQLite (3?) including in-memory mode