Clojurians Log v2
duct
Hello, how to completely disable ragtime migrations in duct?
Hello, could somebody put me on the right track please with congif.edn. I have a problem with adding migrations: https://imgur.com/HLBWrYZ
Can't understand why I have this error
Execution error (ClassCastException) at duct.core/fold-modules$fn (core.clj:145).
duct.database.sql.Boundary cannot be cast to clojure.lang.IFn
@janis.urbis I think you should move migrations to profile.
Like this https://github.com/jahson/blog-film-ratings/blob/master/resources/film_ratings/config.edn#L9-L14
Has anyone played with programmatically controlling the config.edn file? e.g., I want to write a utility script to generate the skeleton of a migration; that script might as well also read config.edn, add the necessary keys, and write config.edn back out.
A challenge is the evaluation of reader literals when reading the config
Why don’t you use duct.core/read-config? https://github.com/duct-framework/core/blob/master/src/duct/core.clj#L116
I was; the challenge was not having the literals evaluate, for example, turning a relative duct/resource file path into an absolute path in the output. Here was the solution I ended up with that resolves the issue. I ended up scrapping the idea entirely because writing the file back out leads to some not-so-human-friendly formatting (even using pprint, or fipp, etc).
(def config-literals ['duct/resource 'duct/env 'ig/ref])
(defn pair-literal [x]
[x #(tagged-literal x %)])
(defn read-config-keep-literals [file]
(duct/read-config
file
(into {} (map pair-literal config-literals))))
Maybe you can use code from duct.core but without default readers?
Like
(some->> source slurp (ig/read-string {:readers {}}))))Or even further https://github.com/weavejester/integrant/blob/b3b8c66644e38838a87081381aaeccd900dd3357/src/integrant/core.cljc#L155
But the formatting will still be an issue though.
The reader issue is resolved in my snippet, above, it’s really just the formatting issue that’s preventing programmatic control, which would be really nice for some interesting developer-experience tooling (auto registering migrations, new handlers, etc)