For those unfamiliar, Perpetuity is an object-relational mapper that follows Martin Fowler's Data Mapper pattern. It is the first implementation of this pattern in Ruby.

Now that Perpetuity's API has been stabilized somewhat, I've been working on a PostgreSQL adapter. This has been the #1 feature request since I began working on it. I don't agree with the usual reasons behind this request, but I don't think it's an unreasonable one. You can't always control what DB you get to use and at least you'll be able to use Perpetuity if you can't use MongoDB in production.

The first thing this made me think of was that there's absolutely no point in keeping the dependency on the moped gem if you're not going to use it, but adding that dependency manually in your app's Gemfile seems unnecessary. Ideally, you shouldn't have to think about your dependencies' dependencies. Obviously, sometimes you do have to think about them, but I try to keep things as close to ideal as I reasonably can.

While discussing this with Kevin Sjöberg in a few of our pairing sessions (he's paired with me multiple times on Perpetuity and has given some very valuable feedback on a lot of it), we discussed separating the adapters into perpetuity-mongodb and perpetuity-postgresql gems. This seems like the best idea so far.

These gems will have perpetuity as a dependency so that you can simply put the adapter gem into your Gemfile and get both the adapter and the main gem, similar to how rspec-rails depends on rspec. This also allows for plugin-style database adapters, allowing Perpetuity to talk to other databases without itself knowing about every available one.