Clojurians Log v2

@weavejester Any chance we can push a few releases sometime soon? https://github.com/duct-framework/duct - Template enhancements (auto reload, updated dependencies) https://github.com/duct-framework/core - Better error message when adding a non-module key in the module space https://github.com/duct-framework/middleware.buddy - New available init-key, :duct.middleware.buddy/authorization

Something I've noticed in migrator.ragtime is that the implementation is tightly-coupled to the SqlDatabase extension of the Database protocol, https://github.com/duct-framework/migrator.ragtime/blob/master/src/duct/migrator/ragtime.clj#L65 Ragtime itself is generic in orientation, so long as there are implementations of Database and Migration for the migratable system under consideration, Ragtime itself will perform migrations. But migrator.ragtime for Duct narrows itself to SQL. Other database types that can conceptually be migrated are then a bit crowded out of the Duct-forward approach (mongo comes to mind). A refactor is possible to loosen the coupling to SqlDatabase, but I don't think it would be possible for the change to be passive, as I think it would need to create an additional hierarchy in the keys where they're currently a bit more flat now (with an assumption of SQL). I'd propose treating an SQL Migrator :duct.migrator.ragtime/sql as a specialization of a (would-be newly) more generic :duct.migrator/ragtime , and moving the currently :duct.migrator.ragtime/sql to :duct.migrator.ragtime.sql/migration. Hypothetically, this would enable other extensions, like a :duct.migrator.ragtime/mongo and :duct.migrator.ragtime.mongo/migration , where an implementing user could (derive :duct.migrator.ragtime/mongo :duct.migrator/ragtime) , and the goal of an init-key on :duct.migrator.ragtime/mongo would be to prepare a ragtime.protocols.DataStore for some given Mongo connector, and then dispatch to init-key for the generic :duct.migrator/ragtime , which would only expect its database argument implement DataStore , which is the sole expectation of ragtime.core/migrate now. I think the fundamental problem here is that duct database components may return various types of Boundary components, that may or may not already implement ragtime.protocols.DataStore , so maybe a somewhat stranger alternative solution would be for init-key on :duct.migrator/ragtime to accept some kind of optional Boundary->DataStore function as a parameter that could do the conversation that https://github.com/duct-framework/migrator.ragtime/blob/master/src/duct/migrator/ragtime.clj#L64 function does now (and default to the SQL-oriented implementation), but I feel it'd be strange to express supplying an optional function like that in a Duct config edn, so I feel it's not that much of a benefit to the relaxing of the API described above. @weavejester, thoughts?