The adapter API for DataMapper has been in a bit of flux recently. When I submitted
my proposal for a talk at MountainWest, adapters were irritatingly complex to write.
You just needed to know too much about DataMapper's internals to be able to write one.
A week before the conference began, I started a significant effort to re-write the API to make
it easier. I succeeded, a little too well; my 30 minute talk only took 15. Since then,
I've written a couple more adapters from scratch, and refined the API further. This post
will serve as notes on the changes that I've made, and a tutorial on writing adapters.
I was just going to post a comment in reply to Adam Wiggins's Database Versioning post, but it ended up being pretty long, so I'll post a response here instead.
I just pushed 0.9.6 of dm-core, dm-more and data_objects up to rubyforge, as well as 0.9.8 of extlib. There's several bugfixes that were applied in the runup to merbcamp. This is also preparing for the imminent release of merb 1.0RC1.
I realized I haven't blogged about (IMHO) the neatest feature of DataMapper's migrations yet. One of the more harrowing experiences for me in Rails is upgrading a production server with live data, and hoping your migration handles all the existing data correctly. You can dump the database, and attempt the migration on a clone, and hand-examine the data to make sure it was correct, but that feels very non-ruby-like to me. With the spec groups and matchers available in DataMapper migrations, though, you can spec your migrations and be certain that it will work correctly, and translate all your edge-case data correctly.
There's a discussion in the datamapper group about how to do migrations. I've thrown together an idealized DSL for how the migrations themselves should look.