Support Non-duct.database.sql Databases

[bdrillard]

The migrate private function currently requires that the given database be strictly implemented as duct.database.sql, so that a migratable store may be created against it.

Ragtime itself is agnostic to the type of datastore migrations are run against, provided the proper protocols are implemented.

It would be handy if migrator.ragtime could accept different, non-sql database configuration, that may still have coherent notions of migrations, e.g. MongoDB (as though via duct-mongodb).

A few possible approaches:

1. Define a ->DataStore protocol, which defines a single get-database method that will return the appropriate object implementing the DataStore protocol, which migrate can call in lieu of its current private function. migrator.ragtime can include a defaulted extension of this protocol against duct.database.sql.Boundary. Other clients can define their own. It would probably be most appropriate to declare such a protocol (without implementation) in ragtime/protocols, and then provide the default implementation for duct.database.sql.Boundary in migrator.ragtime.
2. Add a :get-datastore-fn to the migrator.ragtime config, applied in lieu of the current private function, which would be a client-defined function that similarly take the given database spec and returns a migratable DataStore.
3. Add a :migration-datastore key to the config, which takes a value of an object implementing the DataStore protocol, in lieu of using the :database and :migrations-table keys. This might be the cleanest option.

Thoughts on either of these approaches? Is there one you'd prefer and be open to receiving a PR for?

[weavejester]

Sorry for taking a while to get back to you on this. I'm not totally sure what the best answer is, but I'm leaning toward the idea of making get-database a multimethod that dispatches on some sort of :database-type key, which would default to :sql if it doesn't exist. A :migration-datastore key is also possible, but as it's not going to be used for anything else, I wonder i a :database-type might not be a more direct solution.