duct-framework / migrator.ragtime Goto Github PK

Component doesn't allow to pass in custom migrations table name.

Hello James!

Would it be possible to add a simple example of how to use SQL file based migrations to the README file? I'm trying to figure this out on my own (no luck yet) and such example would be a great help for me (and I dare to guess there will be other people in similar situation). Thanks!

I'm using the dummy up/down (foo) migrations to test-drive this library, and I would expect that the up part is executed on system-init (e.g. per go), and the down part on system-shutdown (e.g. per halt). However, I am only seeing the up bit executed - not the down bit (i.e. the foo table survives halting the system). Is this to be expected? Here is my config, in case it helps:

  :duct.migrator.ragtime/resources {:path "db/sql/migrations"}
  :duct.migrator/ragtime
  {:database #ig/ref :duct.database.sql/hikaricp
   :strategy :raise-error
   :migrations [#ig/ref :duct.migrator.ragtime/resources]
   }

The db/sql/migrations directory simply contains the two files as shown in the README - i.e. foo.up.sql and foo.down.sql.

Many thanks in advance

Currently, if we changed the migration string, (dev) and (go), then ragtime will simply throw

IllegalArgumentException No implementation of method: :run-down! of protocol: #'ragtime.protocols/Migration found for class: nil clojure.core/-cache-protocol-fn (core_deftype.clj:583)

If we already (dev) and (go), then change the migration string and (reset) we have no exception.

it seems due to lack of index which have the previous auto-hash-ids

(defmethod ig/init-key :duct.migrator/ragtime [_ options]
  (migrate {} options))

(defmethod ig/resume-key :duct.migrator/ragtime [_ options _ index]
  (migrate index options))

It would be better to warn instead of throwing unknown exception.

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?